From noreply at rubyforge.org Wed Nov 1 02:06:04 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Nov 2006 02:06:04 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061101070605.3086D5240BCF@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-30 00:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-01 00:06 Message: Just to chime in, I don't see a reason for something like this. The whole point of BDD and RSpec is to guide us along a better path of development. If you're smart enough to know when to stray from the path, you're smart enough to use your editor's TODO tool (or write a simple script to do it for you). ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-30 18:46 Message: which leaves us to: # todo specify "something that needs doing" and then use my editor to find the todos. all good text editors have that built-in. why should we reimplement this in rspec? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 18:30 Message: todo - I like that also. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-30 17:18 Message: how about todo "something that needs doing" instead of implement "something that needs doing" because implement is really just a todo - isn't it? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-10-30 06:33 Message: +1 for implement ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-30 06:07 Message: The suggested "implement" placeholder would be pretty cool. I have generally started fleshing out specs on rails based projects by flurrying through the model specs spewing out minimal specify statements for the limited things I know about them. Usually just throwing in violations as I'm flying through. Then I start running the specs and going through adding the contraints and going for green. It's a pretty noisy "todo" list when running the specs to find the placeholders. It'd be nice to have a more aesthetically pleasing "todo list" to work from. :) But I concur that being able to turn a real spec yellow probably isn't the behavior we're looking for. rake spec:implement or something that produced a spec:doc like format or something would be pretty nice. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 05:12 Message: FWIW - Irony of ironies, there is currently an abhorrently commented out spec in the trunk. And *I'm* the one who put it there. Even still, I'd rather do so and feel a little dirty about it than have the tool make me feel clean. Or even just a little yellow. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 02:57 Message: Writing an entire specify block before a feature is implemented is not what BDD is about. It goes against the red/green/refactor cycle of TDD, which sits at the heart of BDD. For what it's worth, there is a similar feature in NUnit. I don't believe that I've ever seen it used to allow tests to be ignored in advance of implementation. I've only ever seen it used to ignore existing tests that had been passing and were now failing. Worse, I've seen this cause yellow to become the new green (i.e. an acceptable state for commits and sometimes even releases). Absolutely vile. That said, making decisions about behaviour in advance of implementation is very much aligned w/ BDD, even TDD. What would you think about something like this: implement "should support placeholders for yet to exist specs" This would not accept a block. In fact it would raise if you try to give it one. This way you could write placeholders for specs you know you want, but not allow you to put any code in them. Then there could be a command line option that allows you to report on yet-to-implement specs. Of course, if you insist on violating one of the most basic principles of BDD, you can write up your spec code and comment it out. The commented code would be in a logical place, but the tool would not be condoning the practice. Thoughts? David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-30 00:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From aslak.hellesoy at gmail.com Wed Nov 1 14:00:03 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 1 Nov 2006 20:00:03 +0100 Subject: [rspec-devel] Automatic compatibility check for RSpec on Rails Message-ID: <8d961d900611011100w654ac4cam295a894813620765@mail.gmail.com> The short version: Developers *must* run pre_commit prior to committing - it's more important than before. The longer version: Several people are experiencing problems because they have an RSpec on Rails plugin that is incompatible with their installed RSpec gem. Because I'm lazy I made RSpec on Rails able to detect incompatibilities on its own. There are now two files in our codebase that store the current svn revision in their source (via the svn:externals feature - http://svnbook.red-bean.com/en/1.0/ch07s02.html): lib/spec/version.rb vendor/rspec_on_rails/vendor/plugins/rspec/lib/spec/rails/version.rb The latter, when loaded (it's required by rspec_on_rails.rb) will check that the rev numbers are the same in those two files. If they are not, an exception is thrown with a message to the user describing what to do. In order to ensure that these two files get updated with the current svn revision numbers during a commit it is MANDATORY that rake pre_commit be run prior to a commit. This will modify those files with a random comment, which will in turn cause svn to update the $LastChangedRevision tokens in those files during the next commit. (Without this random modification svn will *not* update the $LastChangedRevision tokens in those files). It's a little bit of magic, but it will help us in the long run. Aslak From george at benevolentcode.com Thu Nov 2 23:25:46 2006 From: george at benevolentcode.com (George Anderson) Date: Thu, 2 Nov 2006 23:25:46 -0500 Subject: [rspec-devel] script/generate rspec issue on trunk (rev 1021) Message-ID: <782d66f30611022025l714a8d08qae0c298df6a83d43@mail.gmail.com> I just updated to rev. 1021, built and installed the gem, and updated the plugin to rev. 1021. When I ran "script/generate rspec" I got: Missing RspecGenerator class in script/../config/../vendor/plugins/rspec/generators/rspec/rspec_generator.rb Then in rspec_generator.rb, I changed: class RSpecGenerator < Rails::Generator::Base to class RspecGenerator < Rails::Generator::Base (note the differing capitalization of "spec") After that, "script/generate rspec" ran as expected. Protocol question: Is this (rspec-devel at rubyforge.org) the right forum for raising this issue? Or rspec-users at rubyforge.org? Or add it directly to the tracker? My guess is to vet the issue on this (devel) list in case the problem is on my end. Thanks, George -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061102/cc615e05/attachment.html From george at benevolentcode.com Thu Nov 2 23:57:41 2006 From: george at benevolentcode.com (George Anderson) Date: Thu, 2 Nov 2006 23:57:41 -0500 Subject: [rspec-devel] TextMate bundle (was Re: (no subject) In-Reply-To: <85AAB0F1-45D1-441C-B51D-D1D84C11A511@agileevolved.com> References: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> <85AAB0F1-45D1-441C-B51D-D1D84C11A511@agileevolved.com> Message-ID: <782d66f30611022057v6c153415w59e9c7fce507a1ce@mail.gmail.com> Hi Luke, Thanks for the bundle (of joy). In the "Run Focussed Specification" command, if you set "Save:" to "Current File" you can edit, then run a given spec without having to remember to save the document first. It might save someone (ahem) some head-scratching. Similarly, it seems the "Run Specifications (Normal)" and "Run Specifications (SpecDoc)" commands would benefit from "Save: All Files in Project" since running the command would presumably involve more than one file. Thanks again, George On 10/31/06, Luke Redpath wrote: > > Hi David > > Yes, it does. :) It was one of the things I missed from the Ruby bundle > too. > > It also has standard "run all specs" and "run all specs (specdoc mode)". > > Cheers > Luke > > On 31 Oct 2006, at 21:44, David Lee wrote: > > Hi Luke, > Thanks! > > I haven't actually tried your bundle yet as I don't have my mac here, > *but* > please allow me to ask beforehand: > > does it support the shift-cmd-R 'Run Focused Test (er .. spec)' command? > > that thing rocks my world for Test::Unit > > look forward to checking this out > > cheers, > David > > > On 01/11/2006, at 3:29 AM, Luke Redpath wrote: > > Hi Justin > > Well spotted, I'll fix and check in now. > > Cheers > Luke > > On 31 Oct 2006, at 15:20, Justin Rich wrote: > > Luke, > > Thanks for the bundle....I do like the Rails templates, very cool. > > I did notice one small problem though, in the Context snippet, the scope > is set to be 'source.rub' instead of 'source.ruby'. Hope that helps. > > -------------------------------------------- > name > Context > scope > source.rub > tabTrigger > con > uuid > 1AEC727D-CE27-4A36-AD41-F76C843DAC2B > > -Justin > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061102/ec9b96c0/attachment.html From luke at agileevolved.com Fri Nov 3 05:22:43 2006 From: luke at agileevolved.com (Luke Redpath) Date: Fri, 3 Nov 2006 10:22:43 +0000 Subject: [rspec-devel] TextMate bundle (was Re: (no subject) In-Reply-To: <782d66f30611022057v6c153415w59e9c7fce507a1ce@mail.gmail.com> References: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> <85AAB0F1-45D1-441C-B51D-D1D84C11A511@agileevolved.com> <782d66f30611022057v6c153415w59e9c7fce507a1ce@mail.gmail.com> Message-ID: <97F9CCC7-EDA0-4744-B7AC-2BEF841156B6@agileevolved.com> Hi George Thanks for the comments. I didn't even notice the save option...thanks for pointing it out. I was resorting to a hacky method of saving the file contents to a tempfile. This is much better. I've only used save current file, rather than entire project - im not keen on the second option. The changes have been checked in. Cheers Luke On 3 Nov 2006, at 04:57, George Anderson wrote: > Hi Luke, > > Thanks for the bundle (of joy). In the "Run Focussed > Specification" command, if you set "Save:" to "Current File" you > can edit, then run a given spec without having to remember to save > the document first. It might save someone (ahem) some head- > scratching. > > Similarly, it seems the "Run Specifications (Normal)" and "Run > Specifications (SpecDoc)" commands would benefit from "Save: All > Files in Project" since running the command would presumably > involve more than one file. > > Thanks again, > > George > > On 10/31/06, Luke Redpath wrote: > Hi David > > Yes, it does. :) It was one of the things I missed from the Ruby > bundle too. > > It also has standard "run all specs" and "run all specs (specdoc > mode)". > > Cheers > Luke > > On 31 Oct 2006, at 21:44, David Lee wrote: > >> Hi Luke, >> >> Thanks! >> >> I haven't actually tried your bundle yet as I don't have my mac >> here, *but* >> please allow me to ask beforehand: >> >> does it support the shift-cmd-R 'Run Focused Test (er .. spec)' >> command? >> >> that thing rocks my world for Test::Unit >> >> look forward to checking this out >> >> cheers, >> David >> >> >> On 01/11/2006, at 3:29 AM, Luke Redpath wrote: >> >>> Hi Justin >>> >>> Well spotted, I'll fix and check in now. >>> >>> Cheers >>> Luke >>> >>> On 31 Oct 2006, at 15:20, Justin Rich wrote: >>> >>>> Luke, >>>> >>>> Thanks for the bundle....I do like the Rails templates, very cool. >>>> >>>> I did notice one small problem though, in the Context snippet, >>>> the scope is set to be ' source.rub' instead of 'source.ruby'. >>>> Hope that helps. >>>> >>>> -------------------------------------------- >>>> name >>>> Context >>>> scope >>>> source.rub >>>> tabTrigger >>>> con >>>> uuid >>>> 1AEC727D-CE27-4A36-AD41-F76C843DAC2B >>>> >>>> -Justin >>>> _______________________________________________ >>>> rspec-devel mailing list >>>> rspec-devel at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061103/5b39bfc6/attachment-0001.html From aslak.hellesoy at gmail.com Fri Nov 3 05:46:32 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 3 Nov 2006 11:46:32 +0100 Subject: [rspec-devel] script/generate rspec issue on trunk (rev 1021) In-Reply-To: <782d66f30611022025l714a8d08qae0c298df6a83d43@mail.gmail.com> References: <782d66f30611022025l714a8d08qae0c298df6a83d43@mail.gmail.com> Message-ID: <8d961d900611030246y5cb6ff1by14039166729b7c17@mail.gmail.com> On 11/3/06, George Anderson wrote: > I just updated to rev. 1021, built and installed the gem, and updated the > plugin to rev. 1021. When I ran "script/generate rspec" I got: > > Missing RspecGenerator class in > script/../config/../vendor/plugins/rspec/generators/rspec/rspec_generator.rb > > Then in rspec_generator.rb, I changed: > > class RSpecGenerator < Rails::Generator::Base > > to > > class RspecGenerator < Rails::Generator::Base > > (note the differing capitalization of "spec") > > After that, "script/generate rspec" ran as expected. > Thanks. Fixed on trunk. It was a recent regression caused by cleaning up the spelling of RSpec and a little too much got cleaned up. > > Protocol question: Is this (rspec-devel at rubyforge.org) the right forum for > raising this issue? Or rspec-users at rubyforge.org? Or add it directly to > the tracker? My guess is to vet the issue on this (devel) list in case the > problem is on my end. > For small things like this (that can be fixed in less than 5 minutes) either mailing list is fine. For bigger things, please use the tracker and ask first here if you're in doubt. Cheers, Aslak > Thanks, > > George > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From dchelimsky at gmail.com Fri Nov 3 07:53:34 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 3 Nov 2006 07:53:34 -0500 Subject: [rspec-devel] script/generate rspec issue on trunk (rev 1021) In-Reply-To: <8d961d900611030246y5cb6ff1by14039166729b7c17@mail.gmail.com> References: <782d66f30611022025l714a8d08qae0c298df6a83d43@mail.gmail.com> <8d961d900611030246y5cb6ff1by14039166729b7c17@mail.gmail.com> Message-ID: <57c63afe0611030453x50700f78qb6cd7e4eefd18151@mail.gmail.com> On 11/3/06, aslak hellesoy wrote: > On 11/3/06, George Anderson wrote: > > I just updated to rev. 1021, built and installed the gem, and updated the > > plugin to rev. 1021. When I ran "script/generate rspec" I got: > > > > Missing RspecGenerator class in > > script/../config/../vendor/plugins/rspec/generators/rspec/rspec_generator.rb > > > > Then in rspec_generator.rb, I changed: > > > > class RSpecGenerator < Rails::Generator::Base > > > > to > > > > class RspecGenerator < Rails::Generator::Base > > > > (note the differing capitalization of "spec") > > > > After that, "script/generate rspec" ran as expected. > > > > Thanks. Fixed on trunk. It was a recent regression caused by cleaning > up the spelling of RSpec and a little too much got cleaned up. That was I! Bummer. I wasn't sure if changing the class names from RspecBlah to RSpecBlah would work or not so I changed a couple and specs passed so I figured I was home free and changed them all. Thanks to George, the newest exploratory tester on our team! And thanks to Aslak for the quick turnaround! Cheers, David > > > > > Protocol question: Is this (rspec-devel at rubyforge.org) the right forum for > > raising this issue? Or rspec-users at rubyforge.org? Or add it directly to > > the tracker? My guess is to vet the issue on this (devel) list in case the > > problem is on my end. > > > > For small things like this (that can be fixed in less than 5 minutes) > either mailing list is fine. > For bigger things, please use the tracker and ask first here if you're in doubt. > > Cheers, > Aslak > > > Thanks, > > > > George > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From bkeepers at gmail.com Fri Nov 3 08:06:23 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Fri, 3 Nov 2006 08:06:23 -0500 Subject: [rspec-devel] Running specs with TextMate bundle Message-ID: Luke, Since the last few updates, I haven't been able to run the specs in textmate. It worked the day that you announced it to the list, but then I updated the next day an it hasn't worked since. I just updated a few minutes ago and I am still getting the same error: /tmp/temp_textmate.USgxnG:34: command not found: spec invitation_spec.rb /tmp/temp_textmate.USgxnG:7:in `passed?': undefined method `match' for nil:NilClass (NoMethodError) from /tmp/ temp_textmate.USgxnG:23 Any ideas? Thanks, Brandon From luke at agileevolved.com Fri Nov 3 09:20:42 2006 From: luke at agileevolved.com (Luke Redpath) Date: Fri, 3 Nov 2006 14:20:42 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: References: Message-ID: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> Hi Brandon I was having this problem - it seems to be related to the recent updates to TextMate - you'll probably find that your TM_SUPPORT_PATH variable (Preferences > Advanced) has disappeared. You need to re-add this. See here: http://macromates.com/textmate/manual/shell_commands#search_path Cheers Luke On 3 Nov 2006, at 13:06, Brandon Keepers wrote: > Luke, > > Since the last few updates, I haven't been able to run the specs in > textmate. It worked the day that you announced it to the list, but > then I updated the next day an it hasn't worked since. I just > updated a few minutes ago and I am still getting the same error: > > /tmp/temp_textmate.USgxnG:34: command not found: spec > invitation_spec.rb /tmp/temp_textmate.USgxnG:7:in `passed?': > undefined method `match' for nil:NilClass (NoMethodError) from /tmp/ > temp_textmate.USgxnG:23 > > Any ideas? > > Thanks, > Brandon > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061103/4874bc2a/attachment-0001.html From bkeepers at gmail.com Fri Nov 3 11:17:26 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Fri, 3 Nov 2006 11:17:26 -0500 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> Message-ID: <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> Luke, That didn't seem to do the trick. TM_SUPPORT_PATH was missing, so I set it to /Applications/TextMate.app/Contents/SharedSupport/Support/ lib and I still get the error. Any other suggestions? Thanks, Brandon On Nov 3, 2006, at 9:20 AM, Luke Redpath wrote: > Hi Brandon > > I was having this problem - it seems to be related to the recent > updates to TextMate - you'll probably find that your > TM_SUPPORT_PATH variable (Preferences > Advanced) has disappeared. > You need to re-add this. See here: > > http://macromates.com/textmate/manual/shell_commands#search_path > > Cheers > Luke > > On 3 Nov 2006, at 13:06, Brandon Keepers wrote: > >> Luke, >> >> Since the last few updates, I haven't been able to run the specs in >> textmate. It worked the day that you announced it to the list, but >> then I updated the next day an it hasn't worked since. I just >> updated a few minutes ago and I am still getting the same error: >> >> /tmp/temp_textmate.USgxnG:34: command not found: spec >> invitation_spec.rb /tmp/temp_textmate.USgxnG:7:in `passed?': >> undefined method `match' for nil:NilClass (NoMethodError) from /tmp/ >> temp_textmate.USgxnG:23 >> >> Any ideas? >> >> Thanks, >> Brandon >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From luke at agileevolved.com Fri Nov 3 12:42:03 2006 From: luke at agileevolved.com (Luke Redpath) Date: Fri, 3 Nov 2006 17:42:03 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> Message-ID: <8BFDB202-4C20-4A9F-8220-44002197728A@agileevolved.com> Have you tried restarting TextMate? OSX? Try running an svn up on the bundle too. Cheers Luke On 3 Nov 2006, at 16:17, Brandon Keepers wrote: > Luke, > > That didn't seem to do the trick. TM_SUPPORT_PATH was missing, so I > set it to /Applications/TextMate.app/Contents/SharedSupport/Support/ > lib and I still get the error. Any other suggestions? > > Thanks, > Brandon > > On Nov 3, 2006, at 9:20 AM, Luke Redpath wrote: > >> Hi Brandon >> >> I was having this problem - it seems to be related to the recent >> updates to TextMate - you'll probably find that your >> TM_SUPPORT_PATH variable (Preferences > Advanced) has disappeared. >> You need to re-add this. See here: >> >> http://macromates.com/textmate/manual/shell_commands#search_path >> >> Cheers >> Luke >> >> On 3 Nov 2006, at 13:06, Brandon Keepers wrote: >> >>> Luke, >>> >>> Since the last few updates, I haven't been able to run the specs in >>> textmate. It worked the day that you announced it to the list, but >>> then I updated the next day an it hasn't worked since. I just >>> updated a few minutes ago and I am still getting the same error: >>> >>> /tmp/temp_textmate.USgxnG:34: command not found: spec >>> invitation_spec.rb /tmp/temp_textmate.USgxnG:7:in `passed?': >>> undefined method `match' for nil:NilClass (NoMethodError) from /tmp/ >>> temp_textmate.USgxnG:23 >>> >>> Any ideas? >>> >>> Thanks, >>> Brandon >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061103/f50373ba/attachment.html From dchelimsky at gmail.com Fri Nov 3 13:10:59 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 3 Nov 2006 12:10:59 -0600 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> Message-ID: <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> Are you up to date with svn (rspec)? There were some problems with a couple of revisions around 102O. David On 11/3/06, Brandon Keepers wrote: > Luke, > > That didn't seem to do the trick. TM_SUPPORT_PATH was missing, so I > set it to /Applications/TextMate.app/Contents/SharedSupport/Support/ > lib and I still get the error. Any other suggestions? > > Thanks, > Brandon > > On Nov 3, 2006, at 9:20 AM, Luke Redpath wrote: > > > Hi Brandon > > > > I was having this problem - it seems to be related to the recent > > updates to TextMate - you'll probably find that your > > TM_SUPPORT_PATH variable (Preferences > Advanced) has disappeared. > > You need to re-add this. See here: > > > > http://macromates.com/textmate/manual/shell_commands#search_path > > > > Cheers > > Luke > > > > On 3 Nov 2006, at 13:06, Brandon Keepers wrote: > > > >> Luke, > >> > >> Since the last few updates, I haven't been able to run the specs in > >> textmate. It worked the day that you announced it to the list, but > >> then I updated the next day an it hasn't worked since. I just > >> updated a few minutes ago and I am still getting the same error: > >> > >> /tmp/temp_textmate.USgxnG:34: command not found: spec > >> invitation_spec.rb /tmp/temp_textmate.USgxnG:7:in `passed?': > >> undefined method `match' for nil:NilClass (NoMethodError) from /tmp/ > >> temp_textmate.USgxnG:23 > >> > >> Any ideas? > >> > >> Thanks, > >> Brandon > >> _______________________________________________ > >> rspec-devel mailing list > >> rspec-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From bkeepers at gmail.com Fri Nov 3 14:09:42 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Fri, 3 Nov 2006 14:09:42 -0500 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> Message-ID: <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> I'm actually still running the 0.6.4 release (I'm lazy). Does the TM bundle only work with the latest from SVN? Brandon On Nov 3, 2006, at 1:10 PM, David Chelimsky wrote: > Are you up to date with svn (rspec)? > > There were some problems with a couple of revisions around 102O. > > David > > On 11/3/06, Brandon Keepers wrote: >> Luke, >> >> That didn't seem to do the trick. TM_SUPPORT_PATH was missing, so I >> set it to /Applications/TextMate.app/Contents/SharedSupport/Support/ >> lib and I still get the error. Any other suggestions? >> >> Thanks, >> Brandon >> >> On Nov 3, 2006, at 9:20 AM, Luke Redpath wrote: >> >>> Hi Brandon >>> >>> I was having this problem - it seems to be related to the recent >>> updates to TextMate - you'll probably find that your >>> TM_SUPPORT_PATH variable (Preferences > Advanced) has disappeared. >>> You need to re-add this. See here: >>> >>> http://macromates.com/textmate/manual/shell_commands#search_path >>> >>> Cheers >>> Luke >>> >>> On 3 Nov 2006, at 13:06, Brandon Keepers wrote: >>> >>>> Luke, >>>> >>>> Since the last few updates, I haven't been able to run the specs in >>>> textmate. It worked the day that you announced it to the list, but >>>> then I updated the next day an it hasn't worked since. I just >>>> updated a few minutes ago and I am still getting the same error: >>>> >>>> /tmp/temp_textmate.USgxnG:34: command not found: spec >>>> invitation_spec.rb /tmp/temp_textmate.USgxnG:7:in `passed?': >>>> undefined method `match' for nil:NilClass (NoMethodError) from / >>>> tmp/ >>>> temp_textmate.USgxnG:23 >>>> >>>> Any ideas? >>>> >>>> Thanks, >>>> Brandon >>>> _______________________________________________ >>>> rspec-devel mailing list >>>> rspec-devel at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From luke at agileevolved.com Fri Nov 3 18:07:52 2006 From: luke at agileevolved.com (Luke Redpath) Date: Fri, 3 Nov 2006 23:07:52 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> Message-ID: No the problem does not lie with RSpec. Its definitely down to TextMate. Re-adding the TM_SUPPORT_PATH fixed it for me - the support path contains a script which runs before any shell commands are invoked to make sure the PATH is inherited - this isn't happening so files aren't being found. Try making sure you've got the latest version of TextMate and that you've entered the TM_SUPPORT_PATH properly. Cheers Luke On 3 Nov 2006, at 19:09, Brandon Keepers wrote: > I'm actually still running the 0.6.4 release (I'm lazy). Does the TM > bundle only work with the latest from SVN? > > Brandon > > On Nov 3, 2006, at 1:10 PM, David Chelimsky wrote: > >> Are you up to date with svn (rspec)? >> >> There were some problems with a couple of revisions around 102O. >> >> David >> >> On 11/3/06, Brandon Keepers wrote: >>> Luke, >>> >>> That didn't seem to do the trick. TM_SUPPORT_PATH was missing, so I >>> set it to /Applications/TextMate.app/Contents/SharedSupport/Support/ >>> lib and I still get the error. Any other suggestions? >>> >>> Thanks, >>> Brandon >>> >>> On Nov 3, 2006, at 9:20 AM, Luke Redpath wrote: >>> >>>> Hi Brandon >>>> >>>> I was having this problem - it seems to be related to the recent >>>> updates to TextMate - you'll probably find that your >>>> TM_SUPPORT_PATH variable (Preferences > Advanced) has disappeared. >>>> You need to re-add this. See here: >>>> >>>> http://macromates.com/textmate/manual/shell_commands#search_path >>>> >>>> Cheers >>>> Luke >>>> >>>> On 3 Nov 2006, at 13:06, Brandon Keepers wrote: >>>> >>>>> Luke, >>>>> >>>>> Since the last few updates, I haven't been able to run the >>>>> specs in >>>>> textmate. It worked the day that you announced it to the list, >>>>> but >>>>> then I updated the next day an it hasn't worked since. I just >>>>> updated a few minutes ago and I am still getting the same error: >>>>> >>>>> /tmp/temp_textmate.USgxnG:34: command not found: spec >>>>> invitation_spec.rb /tmp/temp_textmate.USgxnG:7:in `passed?': >>>>> undefined method `match' for nil:NilClass (NoMethodError) from / >>>>> tmp/ >>>>> temp_textmate.USgxnG:23 >>>>> >>>>> Any ideas? >>>>> >>>>> Thanks, >>>>> Brandon >>>>> _______________________________________________ >>>>> rspec-devel mailing list >>>>> rspec-devel at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>>> >>>> _______________________________________________ >>>> rspec-devel mailing list >>>> rspec-devel at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From aslak.hellesoy at gmail.com Sat Nov 4 04:17:33 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 4 Nov 2006 10:17:33 +0100 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> Message-ID: <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> On 11/4/06, Luke Redpath wrote: > No the problem does not lie with RSpec. Its definitely down to > TextMate. Re-adding the TM_SUPPORT_PATH fixed it for me - the support > path contains a script which runs before any shell commands are > invoked to make sure the PATH is inherited - this isn't happening so > files aren't being found. > > Try making sure you've got the latest version of TextMate and that > you've entered the TM_SUPPORT_PATH properly. > I have the latest TM release - r1324 I also have the latest RSpec bundle - r316 Here is what I did: TextMate->Preferences->Advanced (I only had one variable here - TM_ORGANIZATION_NAME) Then I added TM_SUPPORT_PATH=/Applications/TextMate.app/Contents/SharedSupport/Support/ When I run a spec with CMD-SHIFT-R I get: sh: line 1: spec: command not found /tmp/temp_textmate.Y1n1hT:10:in `passed?': undefined method `match' for nil:NilClass (NoMethodError) from /tmp/temp_textmate.Y1n1hT:43 I see that the three commands have a fair amount of duplication, and that they don't have any specs ;-) Would it be possible to extract the ruby code into a separate file, get rid of the duplication and have some specs for it? (The specs could set the TM env vars and run the code). This would hopefully flesh out better error messages from the bundle itself (in the case where certain env vars are missing). One other thing: How does one develop a TM bundle and keep the code in svn? TM seems to want to remove double-clicked .tmbundle directories. Is there a trick I don't know here? Cheers, Aslak > Cheers > Luke > > On 3 Nov 2006, at 19:09, Brandon Keepers wrote: > > > I'm actually still running the 0.6.4 release (I'm lazy). Does the TM > > bundle only work with the latest from SVN? > > > > Brandon > > > > On Nov 3, 2006, at 1:10 PM, David Chelimsky wrote: > > > >> Are you up to date with svn (rspec)? > >> > >> There were some problems with a couple of revisions around 102O. > >> > >> David > >> > >> On 11/3/06, Brandon Keepers wrote: > >>> Luke, > >>> > >>> That didn't seem to do the trick. TM_SUPPORT_PATH was missing, so I > >>> set it to /Applications/TextMate.app/Contents/SharedSupport/Support/ > >>> lib and I still get the error. Any other suggestions? > >>> > >>> Thanks, > >>> Brandon > >>> > >>> On Nov 3, 2006, at 9:20 AM, Luke Redpath wrote: > >>> > >>>> Hi Brandon > >>>> > >>>> I was having this problem - it seems to be related to the recent > >>>> updates to TextMate - you'll probably find that your > >>>> TM_SUPPORT_PATH variable (Preferences > Advanced) has disappeared. > >>>> You need to re-add this. See here: > >>>> > >>>> http://macromates.com/textmate/manual/shell_commands#search_path > >>>> > >>>> Cheers > >>>> Luke > >>>> > >>>> On 3 Nov 2006, at 13:06, Brandon Keepers wrote: > >>>> > >>>>> Luke, > >>>>> > >>>>> Since the last few updates, I haven't been able to run the > >>>>> specs in > >>>>> textmate. It worked the day that you announced it to the list, > >>>>> but > >>>>> then I updated the next day an it hasn't worked since. I just > >>>>> updated a few minutes ago and I am still getting the same error: > >>>>> > >>>>> /tmp/temp_textmate.USgxnG:34: command not found: spec > >>>>> invitation_spec.rb /tmp/temp_textmate.USgxnG:7:in `passed?': > >>>>> undefined method `match' for nil:NilClass (NoMethodError) from / > >>>>> tmp/ > >>>>> temp_textmate.USgxnG:23 > >>>>> > >>>>> Any ideas? > >>>>> > >>>>> Thanks, > >>>>> Brandon > >>>>> _______________________________________________ > >>>>> rspec-devel mailing list > >>>>> rspec-devel at rubyforge.org > >>>>> http://rubyforge.org/mailman/listinfo/rspec-devel > >>>> > >>>> _______________________________________________ > >>>> rspec-devel mailing list > >>>> rspec-devel at rubyforge.org > >>>> http://rubyforge.org/mailman/listinfo/rspec-devel > >>> > >>> _______________________________________________ > >>> rspec-devel mailing list > >>> rspec-devel at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/rspec-devel > >>> > >> _______________________________________________ > >> rspec-devel mailing list > >> rspec-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Wed Nov 1 11:55:21 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Nov 2006 11:55:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6411 ] Can't run Rails specs with ruby Message-ID: <20061101165521.8D3CC5241694@rubyforge.org> Bugs item #6411, was opened at 2006-10-30 20:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6411&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: Can't run Rails specs with ruby Initial Comment: Standing in vendor/rspec_on_rails: ruby spec/models/person_spec.rb /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/expectations/sugar.rb:13:in `_method_missing' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/expectations/sugar.rb:9:in `method_missing' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/runner/context_eval.rb:37:in `method_missing' from spec/models/person_spec.rb:4 from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/runner/context.rb:14:in `initialize' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/spec/rails/context_factory.rb:17:in `create' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/kernel.rb:4:in `context' from spec/models/person_spec.rb:3 ---------------------------------------------------------------------- Comment By: George Anderson (caton) Date: 2006-11-01 11:55 Message: I'm not sure this is isolated to running a spec via "ruby." I've tried the following (in the context of a rails app) with revsions 1000, 1004, and 1006: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~/work/stc_rl_reporting $ rake spec:models (in /Users/george/work/stc_rl_reporting) /usr/local/bin/ruby -I"/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib" "/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/bin/spec" "spec/models/report_spec.rb" "spec/models/site_spec.rb" /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `setup_parts' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_eval.rb:37:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:82:in `method_missing' from /Users/george/work/stc_rl_reporting/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:104:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/bin/spec:18 rake aborted! Command failed with status (1): [/usr/local/bin/ruby -I"/usr/local/lib/ruby...] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~/work/stc_rl_reporting $ spec spec/models/report_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `setup_parts' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_eval.rb:37:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:82:in `method_missing' from /Users/george/work/stc_rl_reporting/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:104:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/bin/spec:18 from /usr/local/bin/spec:18 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~/work/stc_rl_reporting $ ruby spec/models/report_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `setup_parts' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_eval.rb:37:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:82:in `method_missing' from /Users/george/work/stc_rl_reporting/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:104:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from spec/models/report_spec.rb:6 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It seems the issue persists whether you run via ruby, rake, or spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6411&group_id=797 From noreply at rubyforge.org Fri Nov 3 13:14:30 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 3 Nov 2006 13:14:30 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6471 ] Easy way to spec routes Message-ID: <20061103181430.F365D5241628@rubyforge.org> Feature Requests item #6471, was opened at 2006-11-03 11:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Easy way to spec routes Initial Comment: I'd like to specify that my routes are generating correctly, as shown below: context "The EventsController" do controller_name :events specify "should be a EventsController" do controller.should_be_an_instance_of EventsController end specify "should map { :controller => 'events', :action => 'index' } to /events" do routing(:controller => "events", :action => "index").should_equal "/events" end specify "should map { :controller => 'events', :action => 'show', :id => 1 } to /events/1" do routing(:controller => "events", :action => "show", :id => 1).should_equal "/events/1" end specify "should map { :controller => 'events', :action => 'edit', :id => 1 } to /events/1;edit" do routing(:controller => "events", :action => "edit", :id => 1).should_equal "/events/1;edit" end specify "should map { :controller => 'events', :action => 'new' } to /events/new" do routing(:controller => "events", :action => "new").should_equal "/events/new" end end I made it work by adding the following method to Spec::Runner::ContextEval::InstanceMethods def routing(options) # Load routes.rb if it hasn't been loaded ActionController::Routing::Routes.reload if ActionController::Routing::Routes.empty? ActionController::Routing::Routes.generate(options) end Sorry I don't have any specs for it..the rspec_rails 0.6.4 plugin doesn't have any specs to add to. Not sure how robust this will be (it only uses a tiny part of the code from Rails' assert_routing), but so far it's worked for all of my basic routes. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 From bkeepers at gmail.com Sat Nov 4 19:11:31 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Sat, 4 Nov 2006 19:11:31 -0500 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> Message-ID: <3328D784-EDB5-40A0-9FF3-BE90D9C2340C@gmail.com> I still haven't gotten this to work. I've tried re-installing TextMate. TM_SUPPORT_PATH is set to /Applications/TextMate.app/ Contents/SharedSupport/Support/ svn up /Library/Application\ Support/TextMate/Bundles/RSpec.tmbundle/ At revision 316. When I run a spec, I get this error: /tmp/temp_textmate.MdZzi8:34: command not found: spec invitation_spec.rb /tmp/temp_textmate.MdZzi8:7:in `passed?': undefined method `match' for nil:NilClass (NoMethodError) from /tmp/ temp_textmate.MdZzi8:23 Is anyone else having this problem? Thanks, Brandon On Nov 3, 2006, at 6:07 PM, Luke Redpath wrote: > No the problem does not lie with RSpec. Its definitely down to > TextMate. Re-adding the TM_SUPPORT_PATH fixed it for me - the support > path contains a script which runs before any shell commands are > invoked to make sure the PATH is inherited - this isn't happening so > files aren't being found. > > Try making sure you've got the latest version of TextMate and that > you've entered the TM_SUPPORT_PATH properly. > > Cheers > Luke > > On 3 Nov 2006, at 19:09, Brandon Keepers wrote: > >> I'm actually still running the 0.6.4 release (I'm lazy). Does the TM >> bundle only work with the latest from SVN? >> >> Brandon >> >> On Nov 3, 2006, at 1:10 PM, David Chelimsky wrote: >> >>> Are you up to date with svn (rspec)? >>> >>> There were some problems with a couple of revisions around 102O. >>> >>> David >>> >>> On 11/3/06, Brandon Keepers wrote: >>>> Luke, >>>> >>>> That didn't seem to do the trick. TM_SUPPORT_PATH was missing, >>>> so I >>>> set it to /Applications/TextMate.app/Contents/SharedSupport/ >>>> Support/ >>>> lib and I still get the error. Any other suggestions? >>>> >>>> Thanks, >>>> Brandon >>>> >>>> On Nov 3, 2006, at 9:20 AM, Luke Redpath wrote: >>>> >>>>> Hi Brandon >>>>> >>>>> I was having this problem - it seems to be related to the recent >>>>> updates to TextMate - you'll probably find that your >>>>> TM_SUPPORT_PATH variable (Preferences > Advanced) has disappeared. >>>>> You need to re-add this. See here: >>>>> >>>>> http://macromates.com/textmate/manual/shell_commands#search_path >>>>> >>>>> Cheers >>>>> Luke >>>>> >>>>> On 3 Nov 2006, at 13:06, Brandon Keepers wrote: >>>>> >>>>>> Luke, >>>>>> >>>>>> Since the last few updates, I haven't been able to run the >>>>>> specs in >>>>>> textmate. It worked the day that you announced it to the list, >>>>>> but >>>>>> then I updated the next day an it hasn't worked since. I just >>>>>> updated a few minutes ago and I am still getting the same error: >>>>>> >>>>>> /tmp/temp_textmate.USgxnG:34: command not found: spec >>>>>> invitation_spec.rb /tmp/temp_textmate.USgxnG:7:in `passed?': >>>>>> undefined method `match' for nil:NilClass (NoMethodError) from / >>>>>> tmp/ >>>>>> temp_textmate.USgxnG:23 >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> Thanks, >>>>>> Brandon >>>>>> _______________________________________________ >>>>>> rspec-devel mailing list >>>>>> rspec-devel at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>>>> >>>>> _______________________________________________ >>>>> rspec-devel mailing list >>>>> rspec-devel at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>>> >>>> _______________________________________________ >>>> rspec-devel mailing list >>>> rspec-devel at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>>> >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Sat Nov 4 15:02:39 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 4 Nov 2006 15:02:39 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6471 ] Easy way to spec routes Message-ID: <20061104200240.16CE8524179F@rubyforge.org> Feature Requests item #6471, was opened at 2006-11-03 18:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Easy way to spec routes Initial Comment: I'd like to specify that my routes are generating correctly, as shown below: context "The EventsController" do controller_name :events specify "should be a EventsController" do controller.should_be_an_instance_of EventsController end specify "should map { :controller => 'events', :action => 'index' } to /events" do routing(:controller => "events", :action => "index").should_equal "/events" end specify "should map { :controller => 'events', :action => 'show', :id => 1 } to /events/1" do routing(:controller => "events", :action => "show", :id => 1).should_equal "/events/1" end specify "should map { :controller => 'events', :action => 'edit', :id => 1 } to /events/1;edit" do routing(:controller => "events", :action => "edit", :id => 1).should_equal "/events/1;edit" end specify "should map { :controller => 'events', :action => 'new' } to /events/new" do routing(:controller => "events", :action => "new").should_equal "/events/new" end end I made it work by adding the following method to Spec::Runner::ContextEval::InstanceMethods def routing(options) # Load routes.rb if it hasn't been loaded ActionController::Routing::Routes.reload if ActionController::Routing::Routes.empty? ActionController::Routing::Routes.generate(options) end Sorry I don't have any specs for it..the rspec_rails 0.6.4 plugin doesn't have any specs to add to. Not sure how robust this will be (it only uses a tiny part of the code from Rails' assert_routing), but so far it's worked for all of my basic routes. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-04 20:02 Message: This seems like you're testing rails as opposed to specifying the behaviour of your code. Am I missing something? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 From noreply at rubyforge.org Sat Nov 4 23:20:42 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 4 Nov 2006 23:20:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6471 ] Easy way to spec routes Message-ID: <20061105042042.C9ABE524184C@rubyforge.org> Feature Requests item #6471, was opened at 2006-11-03 11:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Easy way to spec routes Initial Comment: I'd like to specify that my routes are generating correctly, as shown below: context "The EventsController" do controller_name :events specify "should be a EventsController" do controller.should_be_an_instance_of EventsController end specify "should map { :controller => 'events', :action => 'index' } to /events" do routing(:controller => "events", :action => "index").should_equal "/events" end specify "should map { :controller => 'events', :action => 'show', :id => 1 } to /events/1" do routing(:controller => "events", :action => "show", :id => 1).should_equal "/events/1" end specify "should map { :controller => 'events', :action => 'edit', :id => 1 } to /events/1;edit" do routing(:controller => "events", :action => "edit", :id => 1).should_equal "/events/1;edit" end specify "should map { :controller => 'events', :action => 'new' } to /events/new" do routing(:controller => "events", :action => "new").should_equal "/events/new" end end I made it work by adding the following method to Spec::Runner::ContextEval::InstanceMethods def routing(options) # Load routes.rb if it hasn't been loaded ActionController::Routing::Routes.reload if ActionController::Routing::Routes.empty? ActionController::Routing::Routes.generate(options) end Sorry I don't have any specs for it..the rspec_rails 0.6.4 plugin doesn't have any specs to add to. Not sure how robust this will be (it only uses a tiny part of the code from Rails' assert_routing), but so far it's worked for all of my basic routes. ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2006-11-04 21:20 Message: re: testing rails. It's basically the same as when you have validations set up in your model. You test to make sure those are working, right? It's certainly behavior, even if Rails takes care of the hard part. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-11-04 19:06 Message: There's also the opposite operation of recognising a url using the routing patterns... also produces matched params hash, plus an "extras" hash. Like specify "should recognise /events/1;edit as { :controller => 'events', :action => 'edit', :id => 1 }" do route_recognise("/events/1;edit").should_equal(:controller => "events", :action => "edit", :id => 1) end This kind of expectation might be mooted by integration speccing. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-11-04 19:01 Message: I had a look at this too a while back. I think there needs to be a second argument to #routing through which you can send the "extra" parameters. I was assuming that these are arbitrary parameters which don't fit into the rest of the route pattern, and are generated out as the query of the url. Does that sound right? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-11-04 14:38 Message: This is very useful for verifying custom routes (config/routes.rb) , which is rather common in Rails apps. It's not testing rails, it's testing *your* routes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-04 13:02 Message: This seems like you're testing rails as opposed to specifying the behaviour of your code. Am I missing something? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 From noreply at rubyforge.org Sat Nov 4 21:01:18 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 4 Nov 2006 21:01:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6471 ] Easy way to spec routes Message-ID: <20061105020118.574FB5241807@rubyforge.org> Feature Requests item #6471, was opened at 2006-11-04 05:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Easy way to spec routes Initial Comment: I'd like to specify that my routes are generating correctly, as shown below: context "The EventsController" do controller_name :events specify "should be a EventsController" do controller.should_be_an_instance_of EventsController end specify "should map { :controller => 'events', :action => 'index' } to /events" do routing(:controller => "events", :action => "index").should_equal "/events" end specify "should map { :controller => 'events', :action => 'show', :id => 1 } to /events/1" do routing(:controller => "events", :action => "show", :id => 1).should_equal "/events/1" end specify "should map { :controller => 'events', :action => 'edit', :id => 1 } to /events/1;edit" do routing(:controller => "events", :action => "edit", :id => 1).should_equal "/events/1;edit" end specify "should map { :controller => 'events', :action => 'new' } to /events/new" do routing(:controller => "events", :action => "new").should_equal "/events/new" end end I made it work by adding the following method to Spec::Runner::ContextEval::InstanceMethods def routing(options) # Load routes.rb if it hasn't been loaded ActionController::Routing::Routes.reload if ActionController::Routing::Routes.empty? ActionController::Routing::Routes.generate(options) end Sorry I don't have any specs for it..the rspec_rails 0.6.4 plugin doesn't have any specs to add to. Not sure how robust this will be (it only uses a tiny part of the code from Rails' assert_routing), but so far it's worked for all of my basic routes. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-11-05 13:01 Message: I had a look at this too a while back. I think there needs to be a second argument to #routing through which you can send the "extra" parameters. I was assuming that these are arbitrary parameters which don't fit into the rest of the route pattern, and are generated out as the query of the url. Does that sound right? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-11-05 08:38 Message: This is very useful for verifying custom routes (config/routes.rb) , which is rather common in Rails apps. It's not testing rails, it's testing *your* routes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-05 07:02 Message: This seems like you're testing rails as opposed to specifying the behaviour of your code. Am I missing something? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 From noreply at rubyforge.org Sat Nov 4 21:06:33 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 4 Nov 2006 21:06:33 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6471 ] Easy way to spec routes Message-ID: <20061105020633.CFBAE524180F@rubyforge.org> Feature Requests item #6471, was opened at 2006-11-04 05:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Easy way to spec routes Initial Comment: I'd like to specify that my routes are generating correctly, as shown below: context "The EventsController" do controller_name :events specify "should be a EventsController" do controller.should_be_an_instance_of EventsController end specify "should map { :controller => 'events', :action => 'index' } to /events" do routing(:controller => "events", :action => "index").should_equal "/events" end specify "should map { :controller => 'events', :action => 'show', :id => 1 } to /events/1" do routing(:controller => "events", :action => "show", :id => 1).should_equal "/events/1" end specify "should map { :controller => 'events', :action => 'edit', :id => 1 } to /events/1;edit" do routing(:controller => "events", :action => "edit", :id => 1).should_equal "/events/1;edit" end specify "should map { :controller => 'events', :action => 'new' } to /events/new" do routing(:controller => "events", :action => "new").should_equal "/events/new" end end I made it work by adding the following method to Spec::Runner::ContextEval::InstanceMethods def routing(options) # Load routes.rb if it hasn't been loaded ActionController::Routing::Routes.reload if ActionController::Routing::Routes.empty? ActionController::Routing::Routes.generate(options) end Sorry I don't have any specs for it..the rspec_rails 0.6.4 plugin doesn't have any specs to add to. Not sure how robust this will be (it only uses a tiny part of the code from Rails' assert_routing), but so far it's worked for all of my basic routes. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-11-05 13:06 Message: There's also the opposite operation of recognising a url using the routing patterns... also produces matched params hash, plus an "extras" hash. Like specify "should recognise /events/1;edit as { :controller => 'events', :action => 'edit', :id => 1 }" do route_recognise("/events/1;edit").should_equal(:controller => "events", :action => "edit", :id => 1) end This kind of expectation might be mooted by integration speccing. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-11-05 13:01 Message: I had a look at this too a while back. I think there needs to be a second argument to #routing through which you can send the "extra" parameters. I was assuming that these are arbitrary parameters which don't fit into the rest of the route pattern, and are generated out as the query of the url. Does that sound right? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-11-05 08:38 Message: This is very useful for verifying custom routes (config/routes.rb) , which is rather common in Rails apps. It's not testing rails, it's testing *your* routes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-05 07:02 Message: This seems like you're testing rails as opposed to specifying the behaviour of your code. Am I missing something? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 From noreply at rubyforge.org Sat Nov 4 16:38:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 4 Nov 2006 16:38:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6471 ] Easy way to spec routes Message-ID: <20061104213826.A85F2A970010@rubyforge.org> Feature Requests item #6471, was opened at 2006-11-03 13:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Easy way to spec routes Initial Comment: I'd like to specify that my routes are generating correctly, as shown below: context "The EventsController" do controller_name :events specify "should be a EventsController" do controller.should_be_an_instance_of EventsController end specify "should map { :controller => 'events', :action => 'index' } to /events" do routing(:controller => "events", :action => "index").should_equal "/events" end specify "should map { :controller => 'events', :action => 'show', :id => 1 } to /events/1" do routing(:controller => "events", :action => "show", :id => 1).should_equal "/events/1" end specify "should map { :controller => 'events', :action => 'edit', :id => 1 } to /events/1;edit" do routing(:controller => "events", :action => "edit", :id => 1).should_equal "/events/1;edit" end specify "should map { :controller => 'events', :action => 'new' } to /events/new" do routing(:controller => "events", :action => "new").should_equal "/events/new" end end I made it work by adding the following method to Spec::Runner::ContextEval::InstanceMethods def routing(options) # Load routes.rb if it hasn't been loaded ActionController::Routing::Routes.reload if ActionController::Routing::Routes.empty? ActionController::Routing::Routes.generate(options) end Sorry I don't have any specs for it..the rspec_rails 0.6.4 plugin doesn't have any specs to add to. Not sure how robust this will be (it only uses a tiny part of the code from Rails' assert_routing), but so far it's worked for all of my basic routes. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-11-04 16:38 Message: This is very useful for verifying custom routes (config/routes.rb) , which is rather common in Rails apps. It's not testing rails, it's testing *your* routes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-04 15:02 Message: This seems like you're testing rails as opposed to specifying the behaviour of your code. Am I missing something? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6471&group_id=797 From noreply at rubyforge.org Sun Nov 5 20:42:14 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 5 Nov 2006 20:42:14 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6508 ] Proper stacktrace for mocks Message-ID: <20061106014214.382A45241A7A@rubyforge.org> Feature Requests item #6508, was opened at 2006-11-05 20:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6508&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Proper stacktrace for mocks Initial Comment: run failing_examples/mocking_example.rb This produces something like: should fail when messages are received out of order Mock 'one two three' received :three out of order (eval):3:in `three' /Users/aslakhellesoy/scm/rspec/trunk/failing_examples/mocking_example.rb:22:in `should fail when messages are received out of order' The first line of the backtrace is bad. It shouldn't be there at all. When --backtrace is on it should show the line in RSpec's code. Can be achieved with extra args to eval (or is it class_eval) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6508&group_id=797 From noreply at rubyforge.org Sun Nov 5 20:46:41 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 5 Nov 2006 20:46:41 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6057 ] strange test output on windows Message-ID: <20061106014641.2BEC05241A75@rubyforge.org> Bugs item #6057, was opened at 2006-10-07 17:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6057&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: alan maybourne (nothingmuch) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: strange test output on windows Initial Comment: on my windows box, when I run a spec, it incorrectly reports the number of specifications. Here's the output from stack_spec.rb in the tutorial (this is all from just running the spec once - it looks as though it's being run multiple times..?): C:\WINDOWS\system32\cmd.exe /c ruby stack_spec.rb -f s A new stack - should be empty Finished in 0.0 seconds 1 specification, 0 failures A new stack - should be empty An empty stack - should not be empty after 'push' Finished in 0.0 seconds 3 specifications, 0 failures A new stack - should be empty An empty stack - should not be empty after 'push' A stack with one item - should return top when you send it 'top' Finished in 0.0 seconds 6 specifications, 0 failures Hit any key to close this window... I didn't change the source code at all from what's available in the tutorial. I also wrote my own very simple class and spec and found the same bug. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-05 20:46 Message: This is a dupe of another bug which is fixed in svn and will be fixed in the 0.7.0 release. It's not related to windows. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-07 21:14 Message: This is a bug that occurs when you run using the ruby command rather than the spec command. If you do the following you shouldn't see it: C:\WINDOWS\system32\cmd.exe /c spec stack_spec.rb -f s Still, we'll leave this open and address it in the context of the ruby command. ---------------------------------------------------------------------- Comment By: alan maybourne (nothingmuch) Date: 2006-10-07 17:37 Message: I forgot to mention, I'm running rspec 0.6.4 and ruby 1.8.4 on windows xp ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6057&group_id=797 From noreply at rubyforge.org Sun Nov 5 17:53:45 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 5 Nov 2006 17:53:45 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6504 ] Running all specs at exit instead of of context end Message-ID: <20061105225345.D73B0A970028@rubyforge.org> Patches item #6504, was opened at 2006-11-05 14:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6504&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shane Duan (wolfdancer) Assigned to: Nobody (None) Summary: Running all specs at exit instead of of context end Initial Comment: Running all specs at the context end causes the same specs being run over and over when loading all the specs in the project. I got help on solving this issue by providing my own class but I thought it should make sense if rspec does it this way. I have logged this at: http://agileworks.blogspot.com/2006/09/buildmaster-surgery-moving-to-rspec.html Cheers Shane ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6504&group_id=797 From dchelimsky at gmail.com Sun Nov 5 22:15:05 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 5 Nov 2006 21:15:05 -0600 Subject: [rspec-devel] heads up Message-ID: <57c63afe0611051915h6e63ddd4v1342f1965c43027c@mail.gmail.com> I'm moving a bunch of RFEs around - apologies for all the noise. David From dchelimsky at gmail.com Mon Nov 6 06:02:18 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 6 Nov 2006 05:02:18 -0600 Subject: [rspec-devel] [ANN] RSpec 0.7.0 Released Message-ID: <57c63afe0611060302o63f5200eo6f6132f19d79e12d@mail.gmail.com> The RSpec Development Team is pleased to announce the release of RSpec 0.7.0. You can get it from http://rubyforge.org/frs/?group_id=797, or "gem install rspec" Note that this release is NOT completely backwards compatible. If you are already using a prior release of rspec, see http://rspec.rubyforge.org/upgrade.html before you upgrade. RSpec is the original BDD framework for Ruby. This release includes a number of significant improvements, most notably in the areas of mocks/stubs and the RSpec on Rails plugin. Learn more at: http://rspec.rubyforge.org/documentation/mocks/index.html http://rspec.rubyforge.org/documentation/rails/index.html See http://rspec.rubyforge.org/changes.html for a complete list of changes. Thanks to all who contributed to this release, and to who all will contribute in the future by using it and providing us with valuable feedback. Happy designing! The RSpec Development Team From noreply at rubyforge.org Mon Nov 6 07:16:35 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 07:16:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6514 ] Document has trivial typos. Message-ID: <20061106121636.553E65240A99@rubyforge.org> Bugs item #6514, was opened at 2006-11-06 21:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shintaro KAKUTANI (kakutani) Assigned to: Nobody (None) Summary: Document has trivial typos. Initial Comment: 0.7.0 controllers.page has some trivial typos. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 From bkeepers at gmail.com Mon Nov 6 09:45:16 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Mon, 6 Nov 2006 09:45:16 -0500 Subject: [rspec-devel] [ANN] RSpec 0.7.0 Released In-Reply-To: <57c63afe0611060302o63f5200eo6f6132f19d79e12d@mail.gmail.com> References: <57c63afe0611060302o63f5200eo6f6132f19d79e12d@mail.gmail.com> Message-ID: Thanks everyone for your hard work! I'm in the process of upgrading one of my rails apps. It looks like there was some changes to how spec_helper sets up the specs. Here is my current version of spec_helper.rb: http://pastie.caboo.se/21433 The first issue is that spec_helper.rb used to require 'controller_mixin', which apparently doesn't exist anymore. I see that the new spec_helper doesn't include that anymore, so I just removed it. You may want to note that in the docs for upgrading. My second issue is that I need to mix in AuthenticatedTestHelper to the context, I was doing this in Spec::Runner::Context#before_context_eval, but that doesn't work anymore. I tried adding this to Test::Rails::TestCase and SpecTestCase, but neither of those worked. Does anyone have any idea how to mix in other helpers? Thanks, Brandon On Nov 6, 2006, at 6:02 AM, David Chelimsky wrote: > The RSpec Development Team is pleased to announce the release of > RSpec 0.7.0. > > You can get it from http://rubyforge.org/frs/?group_id=797, or "gem > install rspec" > > Note that this release is NOT completely backwards compatible. If you > are already using a prior release of rspec, see > http://rspec.rubyforge.org/upgrade.html before you upgrade. > > RSpec is the original BDD framework for Ruby. This release includes a > number of significant improvements, most notably in the areas of > mocks/stubs and the RSpec on Rails plugin. Learn more at: > > http://rspec.rubyforge.org/documentation/mocks/index.html > http://rspec.rubyforge.org/documentation/rails/index.html > > See http://rspec.rubyforge.org/changes.html for a complete list of > changes. > > Thanks to all who contributed to this release, and to who all will > contribute in the future by using it and providing us with valuable > feedback. > > Happy designing! > The RSpec Development Team > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Mon Nov 6 11:21:58 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 6 Nov 2006 10:21:58 -0600 Subject: [rspec-devel] [ANN] RSpec 0.7.0 Released In-Reply-To: References: <57c63afe0611060302o63f5200eo6f6132f19d79e12d@mail.gmail.com> Message-ID: <57c63afe0611060821r2938cc5y8a3c2abdf8b880c1@mail.gmail.com> On 11/6/06, Brandon Keepers wrote: > Thanks everyone for your hard work! > > I'm in the process of upgrading one of my rails apps. It looks like > there was some changes to how spec_helper sets up the specs. Here is > my current version of spec_helper.rb: http://pastie.caboo.se/21433 > > The first issue is that spec_helper.rb used to require > 'controller_mixin', which apparently doesn't exist anymore. I see > that the new spec_helper doesn't include that anymore, so I just > removed it. You may want to note that in the docs for upgrading. Will do - thanks for the feedback! > > My second issue is that I need to mix in AuthenticatedTestHelper to > the context, I was doing this in > Spec::Runner::Context#before_context_eval, but that doesn't work > anymore. I tried adding this to Test::Rails::TestCase and > SpecTestCase, but neither of those worked. > > Does anyone have any idea how to mix in other helpers? You can do it right in your context: context "a context...." do include AuthenticatedTestHelper ... end > > Thanks, > Brandon > > On Nov 6, 2006, at 6:02 AM, David Chelimsky wrote: > > > The RSpec Development Team is pleased to announce the release of > > RSpec 0.7.0. > > > > You can get it from http://rubyforge.org/frs/?group_id=797, or "gem > > install rspec" > > > > Note that this release is NOT completely backwards compatible. If you > > are already using a prior release of rspec, see > > http://rspec.rubyforge.org/upgrade.html before you upgrade. > > > > RSpec is the original BDD framework for Ruby. This release includes a > > number of significant improvements, most notably in the areas of > > mocks/stubs and the RSpec on Rails plugin. Learn more at: > > > > http://rspec.rubyforge.org/documentation/mocks/index.html > > http://rspec.rubyforge.org/documentation/rails/index.html > > > > See http://rspec.rubyforge.org/changes.html for a complete list of > > changes. > > > > Thanks to all who contributed to this release, and to who all will > > contribute in the future by using it and providing us with valuable > > feedback. > > > > Happy designing! > > The RSpec Development Team > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From bkeepers at gmail.com Mon Nov 6 12:04:16 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Mon, 6 Nov 2006 12:04:16 -0500 Subject: [rspec-devel] [ANN] RSpec 0.7.0 Released In-Reply-To: <57c63afe0611060821r2938cc5y8a3c2abdf8b880c1@mail.gmail.com> References: <57c63afe0611060302o63f5200eo6f6132f19d79e12d@mail.gmail.com> <57c63afe0611060821r2938cc5y8a3c2abdf8b880c1@mail.gmail.com> Message-ID: <01EEA137-F068-42E2-AAB9-9210859FE78F@gmail.com> On Nov 6, 2006, at 11:21 AM, David Chelimsky wrote: > You can do it right in your context: > > context "a context...." do > include AuthenticatedTestHelper > ... > end Any way to DRY it up? I use it in 95% of my controller specs. Thanks, Brandon From bkeepers at gmail.com Mon Nov 6 13:20:46 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Mon, 6 Nov 2006 13:20:46 -0500 Subject: [rspec-devel] controller.should_redirect_to in 0.7.0 Message-ID: <71E1E389-4390-4083-BE65-316F1CA597F7@gmail.com> I'm having an issue with controller.should_redirect_to in 0.7.0. Here is an example of my spec: context "A new user signing up" do fixtures :users controller_name :account integrate_views setup do post :signup, :user => {:email => 'quire at example.com', :password => 'quire', :password_confirmation => 'quire' } end specify "should save a valid " do assigns(:user).should_be_valid assigns(:user).should_not_be_new_record end specify "should redirect" do controller.should_redirect_to :controller => "/account", :action => "index" end end Which produces this failure: Spec::Mocks::MockExpectationError in 'A new user signing up should redirect' controller expected call to redirect_to {:controller=>"/ account", :action=>"index"} but it was never received However, if I insert a breakpoint right before that expectation and inspect the response, I can see that the response is a redirect: >> response.redirected_to => {:controller=>"/account", :action=>"index"} Any ideas? Thanks, Brandon From dchelimsky at gmail.com Mon Nov 6 14:28:05 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 6 Nov 2006 13:28:05 -0600 Subject: [rspec-devel] controller.should_redirect_to in 0.7.0 In-Reply-To: <71E1E389-4390-4083-BE65-316F1CA597F7@gmail.com> References: <71E1E389-4390-4083-BE65-316F1CA597F7@gmail.com> Message-ID: <57c63afe0611061128y1068341btdb24f46b7448beaa@mail.gmail.com> controller.should_redirect_to has to come before the action in question. It's like a mock expectation. In fact, it IS a mock expectation under the hood. So you'll have to reorganize your spec to something like this: context "A new user signing up" do fixtures :users controller_name :account integrate_views def do_post post :signup, :user => {:email => 'quire at example.com', :password => 'quire', :password_confirmation => 'quire' } end specify "should save a valid " do do_post assigns(:user).should_be_valid assigns(:user).should_not_be_new_record end specify "should redirect" do controller.should_redirect_to :controller => "/account", :action => "index" do_post end end I'll update the docs to make this more clear. Cheers, David On 11/6/06, Brandon Keepers wrote: > I'm having an issue with controller.should_redirect_to in 0.7.0. > Here is an example of my spec: > > context "A new user signing up" do > fixtures :users > controller_name :account > integrate_views > setup do > post :signup, :user => {:email => 'quire at example.com', :password > => 'quire', > :password_confirmation => 'quire' } > end > > specify "should save a valid " do > assigns(:user).should_be_valid > assigns(:user).should_not_be_new_record > end > > specify "should redirect" do > controller.should_redirect_to :controller => "/account", :action > => "index" > end > end > > Which produces this failure: > > Spec::Mocks::MockExpectationError in 'A new user signing up should > redirect' > controller expected call to redirect_to {:controller=>"/ > account", :action=>"index"} but it was never received > > However, if I insert a breakpoint right before that expectation and > inspect the response, I can see that the response is a redirect: > > >> response.redirected_to > => {:controller=>"/account", :action=>"index"} > > Any ideas? > > Thanks, > Brandon > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Mon Nov 6 11:28:44 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 11:28:44 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6515 ] Couple GET and POST phases of forms Message-ID: <20061106162844.D5CFE52410F5@rubyforge.org> Feature Requests item #6515, was opened at 2006-11-06 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6515&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: Couple GET and POST phases of forms Initial Comment: I'd love to be able to do things like this plugin does for standard Rails tests: http://www.jasongarber.com/articles/2006/10/24/easier-testing-of-forms-form_test_helper In a nutshell, it finally closes the loop between "the empty form sent by a get" and "the filled-in form returned on a post". Instead of blindly posting parameters, you're now actually filling in form fields in the tests. Works with hidden fields and everything, too. It'd be nice to see rspec do something like that. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6515&group_id=797 From noreply at rubyforge.org Mon Nov 6 13:11:20 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 13:11:20 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061106181121.7B8DD52418CD@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Mon Nov 6 12:45:31 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 12:45:31 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061106174532.0D1D7A970007@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Mon Nov 6 12:50:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 12:50:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6519 ] Let RubyGems install dependencies instead of having to do it manually Message-ID: <20061106175059.5AD7C52417AF@rubyforge.org> Feature Requests item #6519, was opened at 2006-11-06 12:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Craig Demyanovich (cdemyanovich) Assigned to: Nobody (None) Summary: Let RubyGems install dependencies instead of having to do it manually Initial Comment: For release 0.7, ZenTest must be installed first. Instead of having to do this manually, it would be nicer if we could do this $ gem install -y rspec or $ gem update -y rspec and let RubyGems do the work. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 From noreply at rubyforge.org Mon Nov 6 11:38:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 11:38:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6514 ] Document has trivial typos. Message-ID: <20061106163813.2045352410E1@rubyforge.org> Bugs item #6514, was opened at 2006-11-06 12:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) Assigned to: Nobody (None) Summary: Document has trivial typos. Initial Comment: 0.7.0 controllers.page has some trivial typos. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-06 16:37 Message: Applied. See http://rspec.rubyforge.org/documentation/rails/writing/controllers.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 From noreply at rubyforge.org Mon Nov 6 12:01:07 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 12:01:07 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6514 ] Document has trivial typos. Message-ID: <20061106170107.843165241160@rubyforge.org> Bugs item #6514, was opened at 2006-11-06 21:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) Assigned to: Nobody (None) Summary: Document has trivial typos. Initial Comment: 0.7.0 controllers.page has some trivial typos. ---------------------------------------------------------------------- >Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-07 02:01 Message: I've overlooked one more typo. (sorry!) --- doc/src/documentation/rails/writing/controllers.page.6514 2006-11-07 01:57:59.000000000 +0900 +++ doc/src/documentation/rails/writing/controllers.page 2006-11-07 01:58:52.000000000 +0900 @@ -83,7 +83,7 @@ get 'action' -controller.should_have_rendered :template = "path/to/template/for/action" +controller.should_have_rendered :template => "path/to/template/for/action" Like should_render above, you can specify :template, :text, or :action. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 01:37 Message: Applied. See http://rspec.rubyforge.org/documentation/rails/writing/controllers.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 From noreply at rubyforge.org Mon Nov 6 12:51:11 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 12:51:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061106175112.28EB2A970007@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Mon Nov 6 12:01:43 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 12:01:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6514 ] Document has trivial typos. Message-ID: <20061106170143.9B8B9524118A@rubyforge.org> Bugs item #6514, was opened at 2006-11-06 21:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) Assigned to: Nobody (None) Summary: Document has trivial typos. Initial Comment: 0.7.0 controllers.page has some trivial typos. ---------------------------------------------------------------------- >Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-07 02:01 Message: I've overlooked one more typo. (sorry!) --- doc/src/documentation/rails/writing/controllers.page.6514 2006-11-07 01:57:59.000000000 +0900 +++ doc/src/documentation/rails/writing/controllers.page 2006-11-07 01:58:52.000000000 +0900 @@ -83,7 +83,7 @@ get 'action' -controller.should_have_rendered :template = "path/to/template/for/action" +controller.should_have_rendered :template => "path/to/template/for/action" Like should_render above, you can specify :template, :text, or :action. ---------------------------------------------------------------------- Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-07 02:01 Message: I've overlooked one more typo. (sorry!) --- doc/src/documentation/rails/writing/controllers.page.6514 2006-11-07 01:57:59.000000000 +0900 +++ doc/src/documentation/rails/writing/controllers.page 2006-11-07 01:58:52.000000000 +0900 @@ -83,7 +83,7 @@ get 'action' -controller.should_have_rendered :template = "path/to/template/for/action" +controller.should_have_rendered :template => "path/to/template/for/action" Like should_render above, you can specify :template, :text, or :action. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 01:37 Message: Applied. See http://rspec.rubyforge.org/documentation/rails/writing/controllers.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 From noreply at rubyforge.org Mon Nov 6 12:43:24 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 12:43:24 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-4792 ] Replaces the Railsy methods in ControllerExecution with http_service method. Message-ID: <20061106174324.AD3025241160@rubyforge.org> Patches item #4792, was opened at 2006-06-17 03:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=4792&group_id=797 Category: None Group: Unstable (example) >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Brasten Sager (brasten) Assigned to: Nobody (None) Summary: Replaces the Railsy methods in ControllerExecution with http_service method. Initial Comment: Uploaded for discussion only. Some tests fail. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:43 Message: This is outdated now ---------------------------------------------------------------------- Comment By: Brasten Sager (brasten) Date: 2006-06-18 21:46 Message: Refined: http_service is a cloned instance of ExecutionContext with TestProcess included. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=4792&group_id=797 From noreply at rubyforge.org Mon Nov 6 12:08:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 12:08:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6514 ] Document has trivial typos. Message-ID: <20061106170813.8662C524118A@rubyforge.org> Bugs item #6514, was opened at 2006-11-06 12:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) Assigned to: Nobody (None) Summary: Document has trivial typos. Initial Comment: 0.7.0 controllers.page has some trivial typos. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-06 17:08 Message: Applied that one as well. Thanks! ---------------------------------------------------------------------- Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-06 17:01 Message: I've overlooked one more typo. (sorry!) --- doc/src/documentation/rails/writing/controllers.page.6514 2006-11-07 01:57:59.000000000 +0900 +++ doc/src/documentation/rails/writing/controllers.page 2006-11-07 01:58:52.000000000 +0900 @@ -83,7 +83,7 @@ get 'action' -controller.should_have_rendered :template = "path/to/template/for/action" +controller.should_have_rendered :template => "path/to/template/for/action" Like should_render above, you can specify :template, :text, or :action. ---------------------------------------------------------------------- Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-06 17:01 Message: I've overlooked one more typo. (sorry!) --- doc/src/documentation/rails/writing/controllers.page.6514 2006-11-07 01:57:59.000000000 +0900 +++ doc/src/documentation/rails/writing/controllers.page 2006-11-07 01:58:52.000000000 +0900 @@ -83,7 +83,7 @@ get 'action' -controller.should_have_rendered :template = "path/to/template/for/action" +controller.should_have_rendered :template => "path/to/template/for/action" Like should_render above, you can specify :template, :text, or :action. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-06 16:37 Message: Applied. See http://rspec.rubyforge.org/documentation/rails/writing/controllers.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 From noreply at rubyforge.org Mon Nov 6 11:37:35 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 11:37:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6514 ] Document has trivial typos. Message-ID: <20061106163736.225BB5241116@rubyforge.org> Bugs item #6514, was opened at 2006-11-06 12:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) Assigned to: Nobody (None) Summary: Document has trivial typos. Initial Comment: 0.7.0 controllers.page has some trivial typos. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-06 16:37 Message: Applied. See http://rspec.rubyforge.org/documentation/rails/writing/controllers.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6514&group_id=797 From noreply at rubyforge.org Mon Nov 6 16:07:10 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 16:07:10 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6523 ] Run rspec on rails without a db Message-ID: <20061106210710.6558E5240BE8@rubyforge.org> Feature Requests item #6523, was opened at 2006-11-06 21:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6523&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Paul Pagel (paulwpagel) Assigned to: Nobody (None) Summary: Run rspec on rails without a db Initial Comment: We need to be able to run the specs without the database. We have no model objects in some of our projects, therefore, no use for the db. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6523&group_id=797 From noreply at rubyforge.org Mon Nov 6 20:35:35 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 20:35:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6519 ] Let RubyGems install dependencies instead of having to do it manually Message-ID: <20061107013535.A720DA97000D@rubyforge.org> Feature Requests item #6519, was opened at 2006-11-06 12:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Craig Demyanovich (cdemyanovich) Assigned to: Nobody (None) Summary: Let RubyGems install dependencies instead of having to do it manually Initial Comment: For release 0.7, ZenTest must be installed first. Instead of having to do this manually, it would be nicer if we could do this $ gem install -y rspec or $ gem update -y rspec and let RubyGems do the work. ---------------------------------------------------------------------- >Comment By: Craig Demyanovich (cdemyanovich) Date: 2006-11-06 20:35 Message: Thanks, Aslak, for clarifying the dependencies. I like your idea. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 20:26 Message: Every release of RSpec is comprised of two artefacts (so far); The RSpec gem and the RSpec plugin. The former represents the core functionality (and vision) of RSpec and BDD in general. The second artefact is "distributed" as a rails plugin (via code tagged in subversion). It is only the latter (the spec/rails Rails plugin) which depends upon ZenTest. RSpec core (the gem) does not. For the sake of convenience, we *could* make the gem depend on ZenTest to make the spec/rails experience smoother. However, I feel that an explicit dependency from the RSpec gem to ZenTest would imply an undesired intrusion of RSpec's desire to be simplistic and pristine (it does not depend on ZenTest). Would it not be better if we implemented a mechanism in spec/rails that informs developers how they need to install a compatible version of ZenTest? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 From noreply at rubyforge.org Mon Nov 6 20:28:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 20:28:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6523 ] Run rspec on rails without a db Message-ID: <20061107012826.49DEB5241B0D@rubyforge.org> Feature Requests item #6523, was opened at 2006-11-06 16:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6523&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Paul Pagel (paulwpagel) Assigned to: Nobody (None) Summary: Run rspec on rails without a db Initial Comment: We need to be able to run the specs without the database. We have no model objects in some of our projects, therefore, no use for the db. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 20:28 Message: How do I reproduce this missing feature? How would you like it to work exactly? Code please. http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6523&group_id=797 From noreply at rubyforge.org Mon Nov 6 20:26:29 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 20:26:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6519 ] Let RubyGems install dependencies instead of having to do it manually Message-ID: <20061107012630.0EDBF5241B0A@rubyforge.org> Feature Requests item #6519, was opened at 2006-11-06 12:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Craig Demyanovich (cdemyanovich) Assigned to: Nobody (None) Summary: Let RubyGems install dependencies instead of having to do it manually Initial Comment: For release 0.7, ZenTest must be installed first. Instead of having to do this manually, it would be nicer if we could do this $ gem install -y rspec or $ gem update -y rspec and let RubyGems do the work. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 20:26 Message: Every release of RSpec is comprised of two artefacts (so far); The RSpec gem and the RSpec plugin. The former represents the core functionality (and vision) of RSpec and BDD in general. The second artefact is "distributed" as a rails plugin (via code tagged in subversion). It is only the latter (the spec/rails Rails plugin) which depends upon ZenTest. RSpec core (the gem) does not. For the sake of convenience, we *could* make the gem depend on ZenTest to make the spec/rails experience smoother. However, I feel that an explicit dependency from the RSpec gem to ZenTest would imply an undesired intrusion of RSpec's desire to be simplistic and pristine (it does not depend on ZenTest). Would it not be better if we implemented a mechanism in spec/rails that informs developers how they need to install a compatible version of ZenTest? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 From noreply at rubyforge.org Tue Nov 7 02:41:39 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 02:41:39 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6519 ] Let RubyGems install dependencies instead of having to do it manually Message-ID: <20061107074139.D11B75240E18@rubyforge.org> Feature Requests item #6519, was opened at 2006-11-06 12:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Craig Demyanovich (cdemyanovich) Assigned to: Nobody (None) Summary: Let RubyGems install dependencies instead of having to do it manually Initial Comment: For release 0.7, ZenTest must be installed first. Instead of having to do this manually, it would be nicer if we could do this $ gem install -y rspec or $ gem update -y rspec and let RubyGems do the work. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 02:41 Message: spec/rails used to be a gem. we made it a plugin to make it easier to maintain install. maybe it's time to revisit the gem option - the structure has changed a bit and i think it's feasible. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-06 23:16 Message: The rails plugin is a plugin because of the generators. We could move the 'spec/rails' library to a gem. Then we'd have: rspec.gem rails_spec.gem The latter could handle dependencies on the rspec and zentest gems. Thoughts? ---------------------------------------------------------------------- Comment By: Craig Demyanovich (cdemyanovich) Date: 2006-11-06 20:35 Message: Thanks, Aslak, for clarifying the dependencies. I like your idea. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 20:26 Message: Every release of RSpec is comprised of two artefacts (so far); The RSpec gem and the RSpec plugin. The former represents the core functionality (and vision) of RSpec and BDD in general. The second artefact is "distributed" as a rails plugin (via code tagged in subversion). It is only the latter (the spec/rails Rails plugin) which depends upon ZenTest. RSpec core (the gem) does not. For the sake of convenience, we *could* make the gem depend on ZenTest to make the spec/rails experience smoother. However, I feel that an explicit dependency from the RSpec gem to ZenTest would imply an undesired intrusion of RSpec's desire to be simplistic and pristine (it does not depend on ZenTest). Would it not be better if we implemented a mechanism in spec/rails that informs developers how they need to install a compatible version of ZenTest? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 From noreply at rubyforge.org Tue Nov 7 05:14:02 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 05:14:02 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6519 ] Let RubyGems install dependencies instead of having to do it manually Message-ID: <20061107101402.A355C5240B31@rubyforge.org> Feature Requests item #6519, was opened at 2006-11-06 17:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Craig Demyanovich (cdemyanovich) Assigned to: Nobody (None) Summary: Let RubyGems install dependencies instead of having to do it manually Initial Comment: For release 0.7, ZenTest must be installed first. Instead of having to do this manually, it would be nicer if we could do this $ gem install -y rspec or $ gem update -y rspec and let RubyGems do the work. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 10:14 Message: To be clear, I'm thinking that the 2nd gem comprises the 'spec/rails' library and expresses the dependencies on zentest and rspec: gem install -y rspec_rails => installs zentest.gem => installs rspec.gem => installs rspec_rails.gem At that point, the generators and spec_helper still need to be installed. That could be done via a command installed w/ rspec_rails or through script/plugin install. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 07:41 Message: spec/rails used to be a gem. we made it a plugin to make it easier to maintain install. maybe it's time to revisit the gem option - the structure has changed a bit and i think it's feasible. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 04:16 Message: The rails plugin is a plugin because of the generators. We could move the 'spec/rails' library to a gem. Then we'd have: rspec.gem rails_spec.gem The latter could handle dependencies on the rspec and zentest gems. Thoughts? ---------------------------------------------------------------------- Comment By: Craig Demyanovich (cdemyanovich) Date: 2006-11-07 01:35 Message: Thanks, Aslak, for clarifying the dependencies. I like your idea. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 01:26 Message: Every release of RSpec is comprised of two artefacts (so far); The RSpec gem and the RSpec plugin. The former represents the core functionality (and vision) of RSpec and BDD in general. The second artefact is "distributed" as a rails plugin (via code tagged in subversion). It is only the latter (the spec/rails Rails plugin) which depends upon ZenTest. RSpec core (the gem) does not. For the sake of convenience, we *could* make the gem depend on ZenTest to make the spec/rails experience smoother. However, I feel that an explicit dependency from the RSpec gem to ZenTest would imply an undesired intrusion of RSpec's desire to be simplistic and pristine (it does not depend on ZenTest). Would it not be better if we implemented a mechanism in spec/rails that informs developers how they need to install a compatible version of ZenTest? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 From noreply at rubyforge.org Mon Nov 6 23:16:24 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 6 Nov 2006 23:16:24 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6519 ] Let RubyGems install dependencies instead of having to do it manually Message-ID: <20061107041625.2C0DDA970002@rubyforge.org> Feature Requests item #6519, was opened at 2006-11-06 17:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Craig Demyanovich (cdemyanovich) Assigned to: Nobody (None) Summary: Let RubyGems install dependencies instead of having to do it manually Initial Comment: For release 0.7, ZenTest must be installed first. Instead of having to do this manually, it would be nicer if we could do this $ gem install -y rspec or $ gem update -y rspec and let RubyGems do the work. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 04:16 Message: The rails plugin is a plugin because of the generators. We could move the 'spec/rails' library to a gem. Then we'd have: rspec.gem rails_spec.gem The latter could handle dependencies on the rspec and zentest gems. Thoughts? ---------------------------------------------------------------------- Comment By: Craig Demyanovich (cdemyanovich) Date: 2006-11-07 01:35 Message: Thanks, Aslak, for clarifying the dependencies. I like your idea. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 01:26 Message: Every release of RSpec is comprised of two artefacts (so far); The RSpec gem and the RSpec plugin. The former represents the core functionality (and vision) of RSpec and BDD in general. The second artefact is "distributed" as a rails plugin (via code tagged in subversion). It is only the latter (the spec/rails Rails plugin) which depends upon ZenTest. RSpec core (the gem) does not. For the sake of convenience, we *could* make the gem depend on ZenTest to make the spec/rails experience smoother. However, I feel that an explicit dependency from the RSpec gem to ZenTest would imply an undesired intrusion of RSpec's desire to be simplistic and pristine (it does not depend on ZenTest). Would it not be better if we implemented a mechanism in spec/rails that informs developers how they need to install a compatible version of ZenTest? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 From luke at agileevolved.com Tue Nov 7 06:21:38 2006 From: luke at agileevolved.com (Luke Redpath) Date: Tue, 7 Nov 2006 11:21:38 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> Message-ID: <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> I've just committed a large refactoring of the bundle commands into a reasonably specced Ruby module in the bundle Support folder (spec_mate.rb), and extracted the commands into some command objects too. Does this work for you? If not, are the error messages any more useful? Cheers Luke > I see that the three commands have a fair amount of duplication, and > that they don't have any specs ;-) > > Would it be possible to extract the ruby code into a separate file, > get rid of the duplication and have some specs for it? (The specs > could set the TM env vars and run the code). This would hopefully > flesh out better error messages from the bundle itself (in the case > where certain env vars are missing). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061107/90ab3bcf/attachment-0001.html From dchelimsky at gmail.com Tue Nov 7 08:23:30 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 7 Nov 2006 07:23:30 -0600 Subject: [rspec-devel] View Spec Tutorial Message-ID: <57c63afe0611070523n3c7c8354me05c48735589fac7@mail.gmail.com> I've put together a little tutorial to get you started on spec'ing views: http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial If you have questions or wish to provide feedback, please do so in comments on the blog. Thanks, David From noreply at rubyforge.org Tue Nov 7 05:40:54 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 05:40:54 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-4690 ] Ordering of mock calls doesn't work in block mode Message-ID: <20061107104054.EB6705240F41@rubyforge.org> Bugs item #4690, was opened at 2006-06-06 23:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Ordering of mock calls doesn't work in block mode Initial Comment: Two failing (and disabled) tests have been added to mock_ordering_test.rb to demonstrate this. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 10:40 Message: I'm not quite sure how we could possibly get this to work w/o some serious gymnastics. As far as the mock is concerned, it gets two calls with the same signature, and then a block that it executes. It has no relationship to what is inside the block. So we'd have to set up some temporary global to identify the current block being executed and ask all objects to register themselves on that. Eek. Unless I'm missing something???? And is this really that useful that it would be worth the contortions? My feeling is no, but I would be happy to look at an example. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-28 00:46 Message: Sorry. My mistake. I tried to look into this too late. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-27 16:10 Message: Brian - in your example, the second should receive says "a1", "b2", but the second call says "b1", "b2". Was that your intent? If you align these the spec passes. specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-27 08:01 Message: I'm getting an issue with the ordered should_receive(:doit) being called twice. It seems the first expectation wins and the second expectation never gets considered. It also seems that the block is a red herring. try: specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-14 13:19 Message: Moving the tests here: def FIXME_test_two_in_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end def FIXME_test_two_out_of_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "b1", "b2" @mock.doit "a1", "b1" @mock.__verify end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 From noreply at rubyforge.org Tue Nov 7 06:02:10 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 06:02:10 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6059 ] Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block Message-ID: <20061107110210.DE0C85240F6C@rubyforge.org> Bugs item #6059, was opened at 2006-10-08 01:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6059&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Lee (davidlee) Assigned to: Nobody (None) Summary: Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block Initial Comment: Controller testing with RSpec + Rails: response is not upated within a specification when same action is called multiple times within a specify block using Rails 1.1.6 and RSpec 0.6.4 The response object is not being updated within a specify block if multiple responses are generated by GETting the same action. This was verified by checking the redirect_url reported. This does not appear to be an issue unless the *same action* is called multiple times within a specify block, eg to test the effect of accessing an action with different permissions or parameters. Calling the action with different parameters did not appear to affect the problem. example: specify "Index should redirect to welcome if already logged in" do # this will redirect to login as user is not logged in. # the presence of this line will break the test. get :index request.session[:user] = 1 # subsequent gets will redirect to welcome # this will be ignored with regard to the response.redirect_url reported get :index response.should_redirect # fails if first line is present: # says the redirect_url equals 'http://test.host/account/login' # which is a leftover from the first get :index response.redirect_url.should_equal 'http://test.host/account/welcome' end breaking the two `get :index` calls out into separate specify blocks alleviates the problem. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 11:02 Message: "breaking the two `get :index` calls out into separate specify blocks alleviates the problem." That's also the BDD way. Given (context) When (single event or set of events) Then (outcomes) The specs could read: Given a user who is logged in - GET index should redirect to welcome Given a user who is NOT logged in - GET index should redirect to login page OR you could have two specs in the same context: GET index - should redirect a logged in user to welcome - should redirect an anonymous user to the login page We will need to support multiple GETS when we add integration specs, so I'll leave this open to keep it on the radar, but we will likely not be supporting this in the context of controller specs. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6059&group_id=797 From noreply at rubyforge.org Tue Nov 7 05:31:08 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 05:31:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6519 ] Let RubyGems install dependencies instead of having to do it manually Message-ID: <20061107103108.C74E25240F26@rubyforge.org> Feature Requests item #6519, was opened at 2006-11-06 12:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Craig Demyanovich (cdemyanovich) Assigned to: Nobody (None) Summary: Let RubyGems install dependencies instead of having to do it manually Initial Comment: For release 0.7, ZenTest must be installed first. Instead of having to do this manually, it would be nicer if we could do this $ gem install -y rspec or $ gem update -y rspec and let RubyGems do the work. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 05:31 Message: It is possible to package generators in gems as long as the gem's name ends with _generator. Rails automatically discovers such gems. So if we want to go the gem way we have to name it rspec_generator or somesuch. Actually, spec/rails was called rspec_generator back in the days when it used to be a gem. I don't remember exactly why we chose to distribute it as a plugin and not package it as a gem. Does anyone else remember? I looked in the mail archives but couldn't find anything. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 05:14 Message: To be clear, I'm thinking that the 2nd gem comprises the 'spec/rails' library and expresses the dependencies on zentest and rspec: gem install -y rspec_rails => installs zentest.gem => installs rspec.gem => installs rspec_rails.gem At that point, the generators and spec_helper still need to be installed. That could be done via a command installed w/ rspec_rails or through script/plugin install. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 02:41 Message: spec/rails used to be a gem. we made it a plugin to make it easier to maintain install. maybe it's time to revisit the gem option - the structure has changed a bit and i think it's feasible. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-06 23:16 Message: The rails plugin is a plugin because of the generators. We could move the 'spec/rails' library to a gem. Then we'd have: rspec.gem rails_spec.gem The latter could handle dependencies on the rspec and zentest gems. Thoughts? ---------------------------------------------------------------------- Comment By: Craig Demyanovich (cdemyanovich) Date: 2006-11-06 20:35 Message: Thanks, Aslak, for clarifying the dependencies. I like your idea. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 20:26 Message: Every release of RSpec is comprised of two artefacts (so far); The RSpec gem and the RSpec plugin. The former represents the core functionality (and vision) of RSpec and BDD in general. The second artefact is "distributed" as a rails plugin (via code tagged in subversion). It is only the latter (the spec/rails Rails plugin) which depends upon ZenTest. RSpec core (the gem) does not. For the sake of convenience, we *could* make the gem depend on ZenTest to make the spec/rails experience smoother. However, I feel that an explicit dependency from the RSpec gem to ZenTest would imply an undesired intrusion of RSpec's desire to be simplistic and pristine (it does not depend on ZenTest). Would it not be better if we implemented a mechanism in spec/rails that informs developers how they need to install a compatible version of ZenTest? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6519&group_id=797 From noreply at rubyforge.org Tue Nov 7 05:46:17 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 05:46:17 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-5487 ] UserEngine can not be loaded after rspec rails plugin is installed Message-ID: <20061107104617.512135240F53@rubyforge.org> Bugs item #5487, was opened at 2006-08-22 08:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5487&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: UserEngine can not be loaded after rspec rails plugin is installed Initial Comment: After install rspec rails plugin, ?rake test? can not run. `const_missing': uninitialized constant UserEngine (NameError) http://dongbin.org/articles/2006/08/22/userengine-can-not-be-loaded-after-rspec-rails-plugin-is-installed ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 10:46 Message: Closing this for the following reasons (in combination): # Submitted anonymously # submitted URL is no longer available # Not enough context information Feel free to reopen it, whoever you are, if this is still a problem for you, but please read this first: http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5487&group_id=797 From noreply at rubyforge.org Tue Nov 7 06:07:55 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 06:07:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6277 ] debris left by stubbing (trunk) [submitted by dastels] Message-ID: <20061107110755.AAA2A5240F78@rubyforge.org> Bugs item #6277, was opened at 2006-10-22 22:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6277&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: debris left by stubbing (trunk) [submitted by dastels] Initial Comment: stubs leave some sort of residue in one file/context (#1) I have: context "Setting the name" do fixtures :users, :roles, :rights controller_name 'admin/dj' setup do roles(:admin).rights << rights(:admin) users(:rod).roles << roles(:admin) @session[:user] = users('rod').id @dj = Dj.new(:id => 1, :name => 'Joe') @dj.stub!(:update_attribute) @dj.stub!(:name).and_return('Dave') Dj.stub!(:find).and_return(@dj) Dj.should_receive(:find).with(:all).and_return([[@dj]]) end specify "should update the name" do @dj.should_receive(:update_attribute).with(:name, 'Dave') post 'set_dj_name', :id => 1, :value => 'Dave' end specify "should render the list" do post 'set_dj_name', :id => 1, :value => 'Dave' response.should_have_rjs :replace_html, 'itemList', /Dave/ end specify "should render the dj data" do post 'set_dj_name', :id => 1, :value => 'Dave' response.should_have_rjs :replace_html, 'itemData', /Dave/ end end in another (#2): context "Asking for a list" do fixtures :djs, :users, :roles, :rights controller_name 'admin/dj' setup do roles(:admin).rights << rights(:admin) users(:rod).roles << roles(:admin) @session[:user] = users('rod').id get 'list' end specify "should get some djs" do assigns('dj_list').should_not_be_nil end specify "should get all djs" do assigns('dj_list').size.should_equal 4 end end if #1 runs first, both specs in #2 fail (the invoked action calls Dj.find(:all). Failure is: "undefined method `find' for Dj:Class" if #2 is run alone, or first, everythign passes. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 11:07 Message: Is this still a problem in 0.7? If so, can you provide some simple spec and code to reproduce? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6277&group_id=797 From noreply at rubyforge.org Tue Nov 7 06:16:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 06:16:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-4690 ] Ordering of mock calls doesn't work in block mode Message-ID: <20061107111650.B72C85240F78@rubyforge.org> Bugs item #4690, was opened at 2006-06-06 19:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Ordering of mock calls doesn't work in block mode Initial Comment: Two failing (and disabled) tests have been added to mock_ordering_test.rb to demonstrate this. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 06:16 Message: I think we can safely reject this RFE. I recorded it for sake of information, not because I really need it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 05:40 Message: I'm not quite sure how we could possibly get this to work w/o some serious gymnastics. As far as the mock is concerned, it gets two calls with the same signature, and then a block that it executes. It has no relationship to what is inside the block. So we'd have to set up some temporary global to identify the current block being executed and ask all objects to register themselves on that. Eek. Unless I'm missing something???? And is this really that useful that it would be worth the contortions? My feeling is no, but I would be happy to look at an example. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-27 20:46 Message: Sorry. My mistake. I tried to look into this too late. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-27 12:10 Message: Brian - in your example, the second should receive says "a1", "b2", but the second call says "b1", "b2". Was that your intent? If you align these the spec passes. specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-27 04:01 Message: I'm getting an issue with the ordered should_receive(:doit) being called twice. It seems the first expectation wins and the second expectation never gets considered. It also seems that the block is a red herring. try: specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-14 09:19 Message: Moving the tests here: def FIXME_test_two_in_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end def FIXME_test_two_out_of_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "b1", "b2" @mock.doit "a1", "b1" @mock.__verify end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 From noreply at rubyforge.org Tue Nov 7 06:24:28 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 06:24:28 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-4690 ] Ordering of mock calls doesn't work in block mode Message-ID: <20061107112428.8242C5240FEB@rubyforge.org> Bugs item #4690, was opened at 2006-06-06 23:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Ordering of mock calls doesn't work in block mode Initial Comment: Two failing (and disabled) tests have been added to mock_ordering_test.rb to demonstrate this. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 11:16 Message: I think we can safely reject this RFE. I recorded it for sake of information, not because I really need it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 10:40 Message: I'm not quite sure how we could possibly get this to work w/o some serious gymnastics. As far as the mock is concerned, it gets two calls with the same signature, and then a block that it executes. It has no relationship to what is inside the block. So we'd have to set up some temporary global to identify the current block being executed and ask all objects to register themselves on that. Eek. Unless I'm missing something???? And is this really that useful that it would be worth the contortions? My feeling is no, but I would be happy to look at an example. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-28 00:46 Message: Sorry. My mistake. I tried to look into this too late. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-27 16:10 Message: Brian - in your example, the second should receive says "a1", "b2", but the second call says "b1", "b2". Was that your intent? If you align these the spec passes. specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-27 08:01 Message: I'm getting an issue with the ordered should_receive(:doit) being called twice. It seems the first expectation wins and the second expectation never gets considered. It also seems that the block is a red herring. try: specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-14 13:19 Message: Moving the tests here: def FIXME_test_two_in_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end def FIXME_test_two_out_of_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "b1", "b2" @mock.doit "a1", "b1" @mock.__verify end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 From noreply at rubyforge.org Tue Nov 7 06:02:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 06:02:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6059 ] Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block Message-ID: <20061107110251.5D5425240F6C@rubyforge.org> Feature Requests item #6059, was opened at 2006-10-08 01:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6059&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Lee (davidlee) Assigned to: Nobody (None) Summary: Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block Initial Comment: Controller testing with RSpec + Rails: response is not upated within a specification when same action is called multiple times within a specify block using Rails 1.1.6 and RSpec 0.6.4 The response object is not being updated within a specify block if multiple responses are generated by GETting the same action. This was verified by checking the redirect_url reported. This does not appear to be an issue unless the *same action* is called multiple times within a specify block, eg to test the effect of accessing an action with different permissions or parameters. Calling the action with different parameters did not appear to affect the problem. example: specify "Index should redirect to welcome if already logged in" do # this will redirect to login as user is not logged in. # the presence of this line will break the test. get :index request.session[:user] = 1 # subsequent gets will redirect to welcome # this will be ignored with regard to the response.redirect_url reported get :index response.should_redirect # fails if first line is present: # says the redirect_url equals 'http://test.host/account/login' # which is a leftover from the first get :index response.redirect_url.should_equal 'http://test.host/account/welcome' end breaking the two `get :index` calls out into separate specify blocks alleviates the problem. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 11:02 Message: Also - moving this over to feature requests - this is by design, not a bug. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 11:02 Message: "breaking the two `get :index` calls out into separate specify blocks alleviates the problem." That's also the BDD way. Given (context) When (single event or set of events) Then (outcomes) The specs could read: Given a user who is logged in - GET index should redirect to welcome Given a user who is NOT logged in - GET index should redirect to login page OR you could have two specs in the same context: GET index - should redirect a logged in user to welcome - should redirect an anonymous user to the login page We will need to support multiple GETS when we add integration specs, so I'll leave this open to keep it on the radar, but we will likely not be supporting this in the context of controller specs. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6059&group_id=797 From noreply at rubyforge.org Tue Nov 7 05:47:29 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 05:47:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6027 ] rSpec for Rails fails on helper teardown if no teardown is defined within context Message-ID: <20061107104730.00C705240F5D@rubyforge.org> Bugs item #6027, was opened at 2006-10-05 07:02 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jan Wikholm (jwikholm) Assigned to: Nobody (None) Summary: rSpec for Rails fails on helper teardown if no teardown is defined within context Initial Comment: rSpec version 0.6.4 & corresponding rspec_for_rails I had a normal rspec generated by script/generate rspec_model company and had written specs for it. All specs pass otherwise but completely Fail on teardown, which is called from spec/spec_helper.rb(line 23) One example: 1) NoMethodError in 'A company (in general) should be invalid without a name' You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occured while evaluating nil.- ./spec/models/../spec_helper.rb:23:in `teardown' That is same thing is printed for every specify block I have in my specs. After doing a simple: def teardown end in each context block the problem disappeared. It's not hard to fix it yourself, but I feel that defining an empty method for the sake of tests passing is not the way to go. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 10:47 Message: Is this still a problem in 0.7? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6027&group_id=797 From noreply at rubyforge.org Tue Nov 7 06:06:01 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 06:06:01 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6094 ] rspec_on_rails pre-commit fails w/ -b option turned off Message-ID: <20061107110601.BB0D65240F74@rubyforge.org> Bugs item #6094, was opened at 2006-10-11 04:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6094&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: rspec_on_rails pre-commit fails w/ -b option turned off Initial Comment: This is in the trunk as of revision 868. Go to ~/vendor/rspec_on_rails/lib/tasks/bootstrap_rspec.rake and remove or comment the line that reads: t.spec_opts = ['-b'] Stand in ~/vendor/rspec_on-rails and execute: ../../bin/spec spec ../../bin/spec specs Everything should pass Now try this: rake pre_commit You'll get the following error (or similar): 1) NoMethodError in 'Given an rjs call to insert html in a div, a 'should_not_have_rjs' spec with no text but wrong element name should pass' You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occured while evaluating nil.size generated_code/routing/generation.rb:30:in `generate_default_path' ./specs/should_not_have_rjs_spec.rb:99:in `setup' /Users/david/projects/ruby/rspec-all/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/spec/runner/context.rb:30:in `run' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 11:06 Message: Nope. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-21 14:20 Message: I cannot reproduce this on trunk. Does this still apply? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6094&group_id=797 From noreply at rubyforge.org Tue Nov 7 05:46:37 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 05:46:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-5487 ] UserEngine can not be loaded after rspec rails plugin is installed Message-ID: <20061107104637.55CE95240F4D@rubyforge.org> Bugs item #5487, was opened at 2006-08-22 08:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5487&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: UserEngine can not be loaded after rspec rails plugin is installed Initial Comment: After install rspec rails plugin, ?rake test? can not run. `const_missing': uninitialized constant UserEngine (NameError) http://dongbin.org/articles/2006/08/22/userengine-can-not-be-loaded-after-rspec-rails-plugin-is-installed ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 10:46 Message: Closing this for the following reasons (in combination): # Submitted anonymously # submitted URL is no longer available # Not enough context information Feel free to reopen it, whoever you are, if this is still a problem for you, but please read this first: http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5487&group_id=797 From aslak.hellesoy at gmail.com Tue Nov 7 10:30:13 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 7 Nov 2006 16:30:13 +0100 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> Message-ID: <8d961d900611070730h64ad26d8j38d2de32bed984a5@mail.gmail.com> On 11/7/06, Luke Redpath wrote: > > > > I've just committed a large refactoring of the bundle commands into a > reasonably specced Ruby module in the bundle Support folder (spec_mate.rb), > and extracted the commands into some command objects too. Does this work for > you? If not, are the error messages any more useful? > I like the way it's organised now, with its own specs. However, I'd prefer to use a different approach for the plugin itself. A couple of days ago (right before 0.7.0) I did some refactorings to RSpec's HTML formatter. It used to output really ugly HTML - it's much better now. I'd like the RSpec.tmbundle to run specs with the HTML formatter. In fact, with a subclass of the HTML formatter that only differes in that it creates links for the stacktrace (txmt://open?url=file://.... links). This means there is no need to parse RSpec's output and generate HTML - it's taken care of by RSpec core's HTML formatter! I have the code locally on my machine. I'll create a patch for you so you can try it out. Would you be willing to move the RSpec.tmbundle to RSpec's svn? I think it would be easier to maintain and distribute from there. Cheers, Aslak > Cheers > Luke > > I see that the three commands have a fair amount of duplication, and > that they don't have any specs ;-) > > Would it be possible to extract the ruby code into a separate file, > get rid of the duplication and have some specs for it? (The specs > could set the TM env vars and run the code). This would hopefully > flesh out better error messages from the bundle itself (in the case > where certain env vars are missing). > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From luke at agileevolved.com Tue Nov 7 11:12:45 2006 From: luke at agileevolved.com (Luke Redpath) Date: Tue, 7 Nov 2006 16:12:45 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <8d961d900611070730h64ad26d8j38d2de32bed984a5@mail.gmail.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <8d961d900611070730h64ad26d8j38d2de32bed984a5@mail.gmail.com> Message-ID: > I like the way it's organised now, with its own specs. However, I'd > prefer to use a different approach for the plugin itself. > > A couple of days ago (right before 0.7.0) I did some refactorings to > RSpec's HTML formatter. It used to output really ugly HTML - it's much > better now. Agreed, this would be much better. I did actually notice there was a HTML formatter and tried it but it was a bit dodgy as you say so I rolled my own basic results printer. > > I'd like the RSpec.tmbundle to run specs with the HTML formatter. In > fact, with a subclass of the HTML formatter that only differes in that > it creates links for the stacktrace (txmt://open?url=file://.... > links). > > This means there is no need to parse RSpec's output and generate HTML > - it's taken care of by RSpec core's HTML formatter! > > I have the code locally on my machine. I'll create a patch for you so > you can try it out. Please do. From what I can see, all you should need to do is pass :format => :html into the runner, stop using the ResultsPrinter and instead simply puts result.raw_output. > > Would you be willing to move the RSpec.tmbundle to RSpec's svn? I > think it would be easier to maintain and distribute from there. I've got no problem with this though it might have to wait a few days as I'm really busy. > > Cheers, > Aslak Cheers Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061107/d2f71333/attachment-0001.html From bkeepers at gmail.com Tue Nov 7 11:18:35 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Tue, 7 Nov 2006 11:18:35 -0500 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> Message-ID: <335CC741-A413-41F9-9170-1309DB760061@gmail.com> On Nov 7, 2006, at 6:21 AM, Luke Redpath wrote: > I've just committed a large refactoring of the bundle commands into > a reasonably specced Ruby module in the bundle Support folder > (spec_mate.rb), and extracted the commands into some command > objects too. Does this work for you? If not, are the error messages > any more useful? > > Cheers > Luke > > Thanks, Luke! It works now. Brandon From luke at agileevolved.com Tue Nov 7 11:45:04 2006 From: luke at agileevolved.com (Luke Redpath) Date: Tue, 7 Nov 2006 16:45:04 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <335CC741-A413-41F9-9170-1309DB760061@gmail.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> Message-ID: <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> Nice...that will teach me not to write my bundle commands spec-first ;) Cheers Luke > On Nov 7, 2006, at 6:21 AM, Luke Redpath wrote: > >> I've just committed a large refactoring of the bundle commands into >> a reasonably specced Ruby module in the bundle Support folder >> (spec_mate.rb), and extracted the commands into some command >> objects too. Does this work for you? If not, are the error messages >> any more useful? >> >> Cheers >> Luke >> >> > > Thanks, Luke! It works now. > > Brandon > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Tue Nov 7 09:39:03 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 09:39:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6541 ] catch-22 using named routes Message-ID: <20061107143904.03F8152412A1@rubyforge.org> Bugs item #6541, was opened at 2006-11-07 09:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: catch-22 using named routes Initial Comment: The recommended way specify controller redirects is to use controller.should_redirect_to 'path or hash' *before* calling the action. However, you cannot use named routes (XXX_url) until the action has been called (it gives 'rewrite' undefined for nil when it tries to call an instance variable in the controller). Can the mock be improved sufficiently to allow named routes to work in advance of the action? One workaround is to instantiate an ActionController::Integration::Session and delegate the named routes to that. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 From noreply at rubyforge.org Tue Nov 7 14:25:42 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 14:25:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6547 ] should_be_redirect broken in 0.7.0 Message-ID: <20061107192542.B43F85241399@rubyforge.org> Bugs item #6547, was opened at 2006-11-07 14:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: should_be_redirect broken in 0.7.0 Initial Comment: A bunch of specs started failing in 0.7.0. A quick check shows that the following spec fails on .should_be_redirect, which should_be_impossible, since the .should_redirect_to (which I've just added) succeeds. The controller code is a simple redirect_to. context "The HarkController" do controller_name :hark integrate_views fixtures :hark_users specify "should allow Vlad the valid user to log in" do controller.should_redirect_to :action => 'index' post :login, :hark => {:username => "vlad", :password => "atest"} response.should_be_redirect end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 From noreply at rubyforge.org Tue Nov 7 12:46:02 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 12:46:02 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6541 ] catch-22 using named routes Message-ID: <20061107174602.5ADC3A970004@rubyforge.org> Bugs item #6541, was opened at 2006-11-07 09:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: catch-22 using named routes Initial Comment: The recommended way specify controller redirects is to use controller.should_redirect_to 'path or hash' *before* calling the action. However, you cannot use named routes (XXX_url) until the action has been called (it gives 'rewrite' undefined for nil when it tries to call an instance variable in the controller). Can the mock be improved sufficiently to allow named routes to work in advance of the action? One workaround is to instantiate an ActionController::Integration::Session and delegate the named routes to that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 12:46 Message: Could you please attach a failing spec as explained here? http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 From noreply at rubyforge.org Tue Nov 7 15:22:19 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 15:22:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6547 ] should_be_redirect broken in 0.7.0 Message-ID: <20061107202219.F307852413BD@rubyforge.org> Bugs item #6547, was opened at 2006-11-07 19:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: should_be_redirect broken in 0.7.0 Initial Comment: A bunch of specs started failing in 0.7.0. A quick check shows that the following spec fails on .should_be_redirect, which should_be_impossible, since the .should_redirect_to (which I've just added) succeeds. The controller code is a simple redirect_to. context "The HarkController" do controller_name :hark integrate_views fixtures :hark_users specify "should allow Vlad the valid user to log in" do controller.should_redirect_to :action => 'index' post :login, :hark => {:username => "vlad", :password => "atest"} response.should_be_redirect end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 20:22 Message: What error are you getting? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 From noreply at rubyforge.org Tue Nov 7 17:04:01 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 17:04:01 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6547 ] should_be_redirect broken in 0.7.0 Message-ID: <20061107220401.6279052413BC@rubyforge.org> Bugs item #6547, was opened at 2006-11-07 19:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: should_be_redirect broken in 0.7.0 Initial Comment: A bunch of specs started failing in 0.7.0. A quick check shows that the following spec fails on .should_be_redirect, which should_be_impossible, since the .should_redirect_to (which I've just added) succeeds. The controller code is a simple redirect_to. context "The HarkController" do controller_name :hark integrate_views fixtures :hark_users specify "should allow Vlad the valid user to log in" do controller.should_redirect_to :action => 'index' post :login, :hark => {:username => "vlad", :password => "atest"} response.should_be_redirect end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 22:04 Message: OK - I've got this fixed but I can't seem to get to svn on rubyforge from my current location. I will commit the fix this evening. Thanks Jay. David ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-11-07 20:36 Message: Do I write good bug reports, or what? ::crickets chirping:: The above spec (with appropriate controller code) shows the output: expected response to be redirect but was not /cygdrive/c/dev/src/eclipse/hark/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:10:in `should_be_redirect' It also appears that response.redirect_url is nil after a redirect... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 20:22 Message: What error are you getting? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 From noreply at rubyforge.org Tue Nov 7 16:25:04 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 16:25:04 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6541 ] catch-22 using named routes Message-ID: <20061107212504.18EC452416EA@rubyforge.org> Bugs item #6541, was opened at 2006-11-07 14:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: catch-22 using named routes Initial Comment: The recommended way specify controller redirects is to use controller.should_redirect_to 'path or hash' *before* calling the action. However, you cannot use named routes (XXX_url) until the action has been called (it gives 'rewrite' undefined for nil when it tries to call an instance variable in the controller). Can the mock be improved sufficiently to allow named routes to work in advance of the action? One workaround is to instantiate an ActionController::Integration::Session and delegate the named routes to that. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-07 21:25 Message: Sorry, failing spec as requested... ---------------------------------------------------------- require File.dirname(__FILE__) + '/../spec_helper' # just so we have something to test class TestController < ApplicationController def index render :text => 'testing' # don't look for view end end # probably redundant with 0.7? context "All controllers (via ApplicationController)" do controller_name :test specify 'should redirect to login if protected page sought and not logged in' do controller.should_redirect_to login_url get :index controller.should_not_be_logged_in redirect.should == login_url end end ---------------------------------------------------------- spec -fs spec/controllers/application_controller_spec.rb /home/jjw/work/northants/config/environment.rb:31: warning: already initialized constant RAILS_CONNECTION_ADAPTERS Creating sqlite in memory database... All controllers (via ApplicationController) - should redirect to login if protected page sought and not logged in (FAILED - 1) 1) NoMethodError in 'All controllers (via ApplicationController) should redirect to login if protected page sought and not logged in' You have a nil object when you didn't expect it! The error occured while evaluating nil.rewrite generated/routing/named_routes/login.rb:2:in `login_url' ./spec/controllers/application_controller_spec.rb:17:in `should redirect to login if protected page sought and not logged in' Finished in 0.004108 seconds 1 specification, 1 failure --------------------------------------------------------- commenting out the offending 'should_redirect_to' shows that the code itself is fine and login_url valid after the call to get:- All controllers (via ApplicationController) - should redirect to login if protected page sought and not logged in Finished in 0.006735 seconds 1 specification, 0 failures ---------------------------------------------------------- Examining the code for ActionController::Base shows that the nil value is an unset instance variable (@url). There is a method 'initialize_current_url' (line 927) which passes @request and @params to UrlRewriter.new, if that's any help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 17:46 Message: Could you please attach a failing spec as explained here? http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 From noreply at rubyforge.org Tue Nov 7 16:37:49 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 16:37:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6541 ] catch-22 using named routes Message-ID: <20061107213749.5438A524175B@rubyforge.org> Bugs item #6541, was opened at 2006-11-07 14:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: catch-22 using named routes Initial Comment: The recommended way specify controller redirects is to use controller.should_redirect_to 'path or hash' *before* calling the action. However, you cannot use named routes (XXX_url) until the action has been called (it gives 'rewrite' undefined for nil when it tries to call an instance variable in the controller). Can the mock be improved sufficiently to allow named routes to work in advance of the action? One workaround is to instantiate an ActionController::Integration::Session and delegate the named routes to that. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-07 21:37 Message: PS: def redirect controller.url_for(response.redirected_to) end # that's because named routes return the path. While should_redirect_to takes paths, response.redirected_to is a Hash. Yes, I know, I know, I've just found out about should_have_redirected_to or whatever it is. I'm still coming to grips with the new equality rules and latest functionality! ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-07 21:25 Message: Sorry, failing spec as requested... ---------------------------------------------------------- require File.dirname(__FILE__) + '/../spec_helper' # just so we have something to test class TestController < ApplicationController def index render :text => 'testing' # don't look for view end end # probably redundant with 0.7? context "All controllers (via ApplicationController)" do controller_name :test specify 'should redirect to login if protected page sought and not logged in' do controller.should_redirect_to login_url get :index controller.should_not_be_logged_in redirect.should == login_url end end ---------------------------------------------------------- spec -fs spec/controllers/application_controller_spec.rb /home/jjw/work/northants/config/environment.rb:31: warning: already initialized constant RAILS_CONNECTION_ADAPTERS Creating sqlite in memory database... All controllers (via ApplicationController) - should redirect to login if protected page sought and not logged in (FAILED - 1) 1) NoMethodError in 'All controllers (via ApplicationController) should redirect to login if protected page sought and not logged in' You have a nil object when you didn't expect it! The error occured while evaluating nil.rewrite generated/routing/named_routes/login.rb:2:in `login_url' ./spec/controllers/application_controller_spec.rb:17:in `should redirect to login if protected page sought and not logged in' Finished in 0.004108 seconds 1 specification, 1 failure --------------------------------------------------------- commenting out the offending 'should_redirect_to' shows that the code itself is fine and login_url valid after the call to get:- All controllers (via ApplicationController) - should redirect to login if protected page sought and not logged in Finished in 0.006735 seconds 1 specification, 0 failures ---------------------------------------------------------- Examining the code for ActionController::Base shows that the nil value is an unset instance variable (@url). There is a method 'initialize_current_url' (line 927) which passes @request and @params to UrlRewriter.new, if that's any help. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-07 17:46 Message: Could you please attach a failing spec as explained here? http://rspec.rubyforge.org/contribute.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797 From noreply at rubyforge.org Tue Nov 7 15:36:46 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 15:36:46 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6547 ] should_be_redirect broken in 0.7.0 Message-ID: <20061107203646.819DD52415D2@rubyforge.org> Bugs item #6547, was opened at 2006-11-07 14:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: should_be_redirect broken in 0.7.0 Initial Comment: A bunch of specs started failing in 0.7.0. A quick check shows that the following spec fails on .should_be_redirect, which should_be_impossible, since the .should_redirect_to (which I've just added) succeeds. The controller code is a simple redirect_to. context "The HarkController" do controller_name :hark integrate_views fixtures :hark_users specify "should allow Vlad the valid user to log in" do controller.should_redirect_to :action => 'index' post :login, :hark => {:username => "vlad", :password => "atest"} response.should_be_redirect end end ---------------------------------------------------------------------- >Comment By: Jay Levitt (jaylev) Date: 2006-11-07 15:36 Message: Do I write good bug reports, or what? ::crickets chirping:: The above spec (with appropriate controller code) shows the output: expected response to be redirect but was not /cygdrive/c/dev/src/eclipse/hark/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:10:in `should_be_redirect' It also appears that response.redirect_url is nil after a redirect... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 15:22 Message: What error are you getting? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 From bkeepers at gmail.com Tue Nov 7 22:01:06 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Tue, 7 Nov 2006 22:01:06 -0500 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> Message-ID: <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> Uh, oh. I broke it! I upgraded to 0.7.0 and now I get this: /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/ sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/ lib/spec/expectations/sugar.rb:13:in `_method_missing' from /opt/ local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/ sugar.rb:9:in `method_missing' from /opt/local/lib/ruby/gems/1.8/gems/ rspec-0.7.0/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./stories_controller_spec.rb:9 from /opt/local/lib/ruby/gems/1.8/ gems/rspec-0.7.0/lib/spec/runner/context.rb:14:in `initialize' from / Users/brandon/projects/stories/config/../vendor/plugins/rspec/lib/ spec/rails/context_factory.rb:17:in `create' from /Users/brandon/ projects/stories/vendor/plugins/rspec/lib/extensions/kernel.rb:4:in `context' from ./stories_controller_spec.rb:8 from /opt/local/lib/ ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from / opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/bin/spec:14 from /opt/ local/lib/ruby/gems/1.8/gems/rspec-0.7.0/bin/spec:8 from /opt/local/ bin/spec:18 RSpecMate :: Running Specifications An error occurred private method `split' called for nil:NilClass I've tried restarting TextMate and checked the TM_SUPPORT_PATH. Any ideas? Brandon On Nov 7, 2006, at 11:45 AM, Luke Redpath wrote: > Nice...that will teach me not to write my bundle commands spec- > first ;) > > Cheers > Luke From luke at agileevolved.com Wed Nov 8 04:12:10 2006 From: luke at agileevolved.com (Luke Redpath) Date: Wed, 8 Nov 2006 09:12:10 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> Message-ID: <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> Its working for me on 0.7 - are sure it isn't a problem with your specs and the new release (there are some compatibility issues). Have you tried running your specs manually? Cheers Luke On 8 Nov 2006, at 03:01, Brandon Keepers wrote: > Uh, oh. I broke it! > > I upgraded to 0.7.0 and now I get this: > > /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/ > sugar.rb:13:in `call': undefined method `fixtures' for # > (NoMethodError) from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/ > lib/spec/expectations/sugar.rb:13:in `_method_missing' from /opt/ > local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/ > sugar.rb:9:in `method_missing' from /opt/local/lib/ruby/gems/1.8/gems/ > rspec-0.7.0/lib/spec/runner/context_eval.rb:37:in `method_missing' > from ./stories_controller_spec.rb:9 from /opt/local/lib/ruby/gems/1.8/ > gems/rspec-0.7.0/lib/spec/runner/context.rb:14:in `initialize' from / > Users/brandon/projects/stories/config/../vendor/plugins/rspec/lib/ > spec/rails/context_factory.rb:17:in `create' from /Users/brandon/ > projects/stories/vendor/plugins/rspec/lib/extensions/kernel.rb:4:in > `context' from ./stories_controller_spec.rb:8 from /opt/local/lib/ > ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from / > opt/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/bin/spec:14 from /opt/ > local/lib/ruby/gems/1.8/gems/rspec-0.7.0/bin/spec:8 from /opt/local/ > bin/spec:18 > RSpecMate :: Running Specifications > An error occurred > private method `split' called for nil:NilClass > > I've tried restarting TextMate and checked the TM_SUPPORT_PATH. Any > ideas? > > Brandon > > On Nov 7, 2006, at 11:45 AM, Luke Redpath wrote: > >> Nice...that will teach me not to write my bundle commands spec- >> first ;) >> >> Cheers >> Luke > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From brandon at collectiveidea.com Tue Nov 7 23:11:19 2006 From: brandon at collectiveidea.com (Brandon Keepers) Date: Tue, 7 Nov 2006 23:11:19 -0500 Subject: [rspec-devel] controller.session not same as session? Message-ID: <8427FDD9-8AF8-4E82-B78D-5C2A3669FA80@collectiveidea.com> The spec: context "A user logging out" do fixtures :users controller_name :account setup do login_as :quentin users(:quentin).remember_me request.cookies["auth_token"] = cookie_for(:quentin) end def logout get :logout end specify "should unset :user in session" do logout controller.session[:user].should_be_nil end specify "should unset :user in controller.session" do logout controller.session[:user].should_be_nil end end The result: A user logging out - should unset :user in controller.session - should unset :user in session (FAILED - 1) - should be redirected - should delete remember_me token 1) Spec::Expectations::ExpectationNotMetError in 'A user logging out should unset :user in session' 1 should be nil ./spec/controllers/account_controller_spec.rb:149:in `should unset :user in session' Throwing a breakpoint in and examining the two reveals: >> session => #1, "flash"=>{}}> >> controller.session => #nil, "flash"=>{:notice=>"You have been logged out."}}> >> Am I doing something wrong? Brandon -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061107/b8d4b651/attachment.bin From noreply at rubyforge.org Wed Nov 8 04:21:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 04:21:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6555 ] should_have_tag does not match documentation Message-ID: <20061108092127.B56365240EAB@rubyforge.org> Bugs item #6555, was opened at 2006-11-08 09:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: should_have_tag does not match documentation Initial Comment: http://rspec.rubyforge.org/documentation/rails/writing/views.html says should_have_tag takes symbols as arguments. Should_have_tag says otherwise. require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def index() render :inline => '

Hello

'; end end context 'Test Controller' do controller_name :test integrate_views specify 'presents h1' do get :index response.should_have_tag :h1, :content => 'Hello' end end spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:28:in `find_tag': (SyntaxError) SyntaxError in should_have_tag(tag, *opts) * tag should be the name of the tag (like 'div', or 'select' without '<' or '>') * opts should be a Hash of key value pairs from /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:5:in `should_have_tag' from /home/jjw/work/northants/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:22:in `should_have_tag' from ./spec/controllers/test_controller_spec.rb:13:in `__instance_exec0' from ... Whereas strings work fine... response.should_have_tag 'h1', :content => 'Hello' spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller - presents h1 Finished in 0.007113 seconds 1 specification, 0 failures Either the docs or the code should be adjusted. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 From noreply at rubyforge.org Tue Nov 7 21:15:35 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 7 Nov 2006 21:15:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6547 ] should_be_redirect broken in 0.7.0 Message-ID: <20061108021535.5C0215241B63@rubyforge.org> Bugs item #6547, was opened at 2006-11-07 19:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: should_be_redirect broken in 0.7.0 Initial Comment: A bunch of specs started failing in 0.7.0. A quick check shows that the following spec fails on .should_be_redirect, which should_be_impossible, since the .should_redirect_to (which I've just added) succeeds. The controller code is a simple redirect_to. context "The HarkController" do controller_name :hark integrate_views fixtures :hark_users specify "should allow Vlad the valid user to log in" do controller.should_redirect_to :action => 'index' post :login, :hark => {:username => "vlad", :password => "atest"} response.should_be_redirect end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 02:15 Message: fixed in trunk as of revision 1050 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 22:04 Message: OK - I've got this fixed but I can't seem to get to svn on rubyforge from my current location. I will commit the fix this evening. Thanks Jay. David ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-11-07 20:36 Message: Do I write good bug reports, or what? ::crickets chirping:: The above spec (with appropriate controller code) shows the output: expected response to be redirect but was not /cygdrive/c/dev/src/eclipse/hark/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:10:in `should_be_redirect' It also appears that response.redirect_url is nil after a redirect... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 20:22 Message: What error are you getting? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 From noreply at rubyforge.org Wed Nov 8 04:39:00 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 04:39:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6555 ] should_have_tag does not match documentation Message-ID: <20061108093900.3CDFD5240E42@rubyforge.org> Bugs item #6555, was opened at 2006-11-08 09:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: should_have_tag does not match documentation Initial Comment: http://rspec.rubyforge.org/documentation/rails/writing/views.html says should_have_tag takes symbols as arguments. Should_have_tag says otherwise. require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def index() render :inline => '

Hello

'; end end context 'Test Controller' do controller_name :test integrate_views specify 'presents h1' do get :index response.should_have_tag :h1, :content => 'Hello' end end spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:28:in `find_tag': (SyntaxError) SyntaxError in should_have_tag(tag, *opts) * tag should be the name of the tag (like 'div', or 'select' without '<' or '>') * opts should be a Hash of key value pairs from /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:5:in `should_have_tag' from /home/jjw/work/northants/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:22:in `should_have_tag' from ./spec/controllers/test_controller_spec.rb:13:in `__instance_exec0' from ... Whereas strings work fine... response.should_have_tag 'h1', :content => 'Hello' spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller - presents h1 Finished in 0.007113 seconds 1 specification, 0 failures Either the docs or the code should be adjusted. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 09:38 Message: Should we adjust docs, or support symbols? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 From dchelimsky at gmail.com Wed Nov 8 05:01:49 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 8 Nov 2006 04:01:49 -0600 Subject: [rspec-devel] controller.session not same as session? In-Reply-To: <8427FDD9-8AF8-4E82-B78D-5C2A3669FA80@collectiveidea.com> References: <8427FDD9-8AF8-4E82-B78D-5C2A3669FA80@collectiveidea.com> Message-ID: <57c63afe0611080201i23adef7cxbc3eb8946e219a4@mail.gmail.com> On 11/7/06, Brandon Keepers wrote: > The spec: > > context "A user logging out" do > fixtures :users > controller_name :account > > setup do > login_as :quentin > users(:quentin).remember_me > request.cookies["auth_token"] = cookie_for(:quentin) > end > > def logout > get :logout > end > > specify "should unset :user in session" do > logout > controller.session[:user].should_be_nil > end > > specify "should unset :user in controller.session" do > logout > controller.session[:user].should_be_nil > end > end > > The result: > > A user logging out > - should unset :user in controller.session > - should unset :user in session (FAILED - 1) > - should be redirected > - should delete remember_me token > > 1) > Spec::Expectations::ExpectationNotMetError in 'A user logging out > should unset :user in session' > 1 should be nil > ./spec/controllers/account_controller_spec.rb:149:in `should > unset :user in session' > > Throwing a breakpoint in and examining the two reveals: > > >> session > => #1, > "flash"=>{}}> > >> controller.session > => # {:return_to=>nil, "flash"=>{:notice=>"You have been logged out."}}> > >> > > Am I doing something wrong? The spec names say "session" and "controller.session", but both are coded to go after "controller.session". Since each spec gets run in a brand new instance of the context, it makes sense that these would be two different objects. What doesn't make sense is that one passes and one fails. Would you kindly file a bug? FYI - The following spec passes for me in isolation and integration modes: specify "session should be the same object as controller session" do get 'some_action' session.should_equal controller.session end Thanks, David > > Brandon > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From dchelimsky at gmail.com Wed Nov 8 05:29:05 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 8 Nov 2006 04:29:05 -0600 Subject: [rspec-devel] controller.session not same as session? In-Reply-To: <57c63afe0611080201i23adef7cxbc3eb8946e219a4@mail.gmail.com> References: <8427FDD9-8AF8-4E82-B78D-5C2A3669FA80@collectiveidea.com> <57c63afe0611080201i23adef7cxbc3eb8946e219a4@mail.gmail.com> Message-ID: <57c63afe0611080229v7ce91f6fh46f043c670827f14@mail.gmail.com> On 11/8/06, David Chelimsky wrote: > On 11/7/06, Brandon Keepers wrote: > > The spec: > > > > context "A user logging out" do > > fixtures :users > > controller_name :account > > > > setup do > > login_as :quentin > > users(:quentin).remember_me > > request.cookies["auth_token"] = cookie_for(:quentin) > > end > > > > def logout > > get :logout > > end > > > > specify "should unset :user in session" do > > logout > > controller.session[:user].should_be_nil > > end > > > > specify "should unset :user in controller.session" do > > logout > > controller.session[:user].should_be_nil > > end > > end > > > > The result: > > > > A user logging out > > - should unset :user in controller.session > > - should unset :user in session (FAILED - 1) > > - should be redirected > > - should delete remember_me token > > > > 1) > > Spec::Expectations::ExpectationNotMetError in 'A user logging out > > should unset :user in session' > > 1 should be nil > > ./spec/controllers/account_controller_spec.rb:149:in `should > > unset :user in session' > > > > Throwing a breakpoint in and examining the two reveals: > > > > >> session > > => #1, > > "flash"=>{}}> > > >> controller.session > > => # > {:return_to=>nil, "flash"=>{:notice=>"You have been logged out."}}> > > >> > > > > Am I doing something wrong? > > The spec names say "session" and "controller.session", but both are > coded to go after "controller.session". Since each spec gets run in a > brand new instance of the context, it makes sense that these would be > two different objects. > > What doesn't make sense is that one passes and one fails. > > Would you kindly file a bug? > > FYI - The following spec passes for me in isolation and integration modes: > > specify "session should be the same object as controller session" do > get 'some_action' > session.should_equal controller.session > end > > Thanks, > David PS - investigating further, session is available before and after the action, but controller.session is only available after. I added and resolved RFE [#6560] to address this. In trunk. Cheers, David > > > > > Brandon > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > From bkeepers at gmail.com Wed Nov 8 08:29:15 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Wed, 8 Nov 2006 08:29:15 -0500 Subject: [rspec-devel] controller.session not same as session? In-Reply-To: <57c63afe0611080229v7ce91f6fh46f043c670827f14@mail.gmail.com> References: <8427FDD9-8AF8-4E82-B78D-5C2A3669FA80@collectiveidea.com> <57c63afe0611080201i23adef7cxbc3eb8946e219a4@mail.gmail.com> <57c63afe0611080229v7ce91f6fh46f043c670827f14@mail.gmail.com> Message-ID: <2D78BAB4-0839-469F-8601-61E6F11E7750@gmail.com> On Nov 8, 2006, at 5:29 AM, David Chelimsky wrote: > PS - investigating further, session is available before and after the > action, but controller.session is only available after. > > I added and resolved RFE [#6560] to address this. In trunk. > > Cheers, > David Thanks, David! Brandon From bkeepers at gmail.com Wed Nov 8 08:33:08 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Wed, 8 Nov 2006 08:33:08 -0500 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> Message-ID: On Nov 8, 2006, at 4:12 AM, Luke Redpath wrote: > Its working for me on 0.7 - are sure it isn't a problem with your > specs and the new release (there are some compatibility issues). Have > you tried running your specs manually? Yes, I've gone through and they are all passing from the command line. > Cheers > Luke Brandon From aslak.hellesoy at gmail.com Wed Nov 8 08:38:08 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 8 Nov 2006 14:38:08 +0100 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: References: <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> Message-ID: <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> On 11/8/06, Brandon Keepers wrote: > > On Nov 8, 2006, at 4:12 AM, Luke Redpath wrote: > > > Its working for me on 0.7 - are sure it isn't a problem with your > > specs and the new release (there are some compatibility issues). Have > > you tried running your specs manually? > > Yes, I've gone through and they are all passing from the command line. > Could it be that you have two rubies installed and that TM is picking up a different one than your shell? That seems to be the case with me. Aslak > > Cheers > > Luke > > Brandon > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From luke at agileevolved.com Wed Nov 8 08:39:09 2006 From: luke at agileevolved.com (Luke Redpath) Date: Wed, 8 Nov 2006 13:39:09 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> Message-ID: <274039EB-EEA0-44FE-9EAC-7B1ABC43B808@agileevolved.com> What happens if you try and run it in TextMate using the normal Ruby Run command? It does seem to be failing at the spec level. Cheers Luke On 8 Nov 2006, at 13:33, Brandon Keepers wrote: > > On Nov 8, 2006, at 4:12 AM, Luke Redpath wrote: > >> Its working for me on 0.7 - are sure it isn't a problem with your >> specs and the new release (there are some compatibility issues). Have >> you tried running your specs manually? > > Yes, I've gone through and they are all passing from the command line. > >> Cheers >> Luke > > Brandon > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From bkeepers at gmail.com Wed Nov 8 08:58:54 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Wed, 8 Nov 2006 08:58:54 -0500 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <274039EB-EEA0-44FE-9EAC-7B1ABC43B808@agileevolved.com> References: <1CA54126-04FC-4ECD-83E6-909B223942BC@agileevolved.com> <6423A0AF-99BE-41B2-A59B-56B9C51B3A70@gmail.com> <57c63afe0611031010j29c9f29am24dc136a94add08d@mail.gmail.com> <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <274039EB-EEA0-44FE-9EAC-7B1ABC43B808@agileevolved.com> Message-ID: <27B5F138-2102-42F0-915D-715C21E342A6@gmail.com> Luke, On Nov 8, 2006, at 8:39 AM, Luke Redpath wrote: > What happens if you try and run it in TextMate using the normal Ruby > Run command? The normal ruby command works fine. > It does seem to be failing at the spec level. > > Cheers > Luke Thanks, Brandon From aslak.hellesoy at gmail.com Wed Nov 8 09:07:15 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 8 Nov 2006 15:07:15 +0100 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> References: <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> Message-ID: <8d961d900611080607w7d06cd2dp930012db9454671b@mail.gmail.com> On 11/8/06, aslak hellesoy wrote: > On 11/8/06, Brandon Keepers wrote: > > > > On Nov 8, 2006, at 4:12 AM, Luke Redpath wrote: > > > > > Its working for me on 0.7 - are sure it isn't a problem with your > > > specs and the new release (there are some compatibility issues). Have > > > you tried running your specs manually? > > > > Yes, I've gone through and they are all passing from the command line. > > > > Could it be that you have two rubies installed and that TM is picking > up a different one than your shell? > > That seems to be the case with me. > I have an old ruby (1.8.2) in /usr/bin/ruby that came with OS X. I also have ruby 1.8.4 in /usr/local/bin/ruby (built myself) I have a ~/.bash_login that puts /usr/local/bin early in the path, so in my everyday coding, I get 1.8.4. However, it seems that shebang commands (the RSpec.tmbundle commands and the spec script) *do not* get the PATH set in ~/.bash_login. This is explained here: http://macromates.com/textmate/manual/shell_commands#search_path It looks like I have to edit my ~/.MacOSX/environment.plist in order to fix my PATH so shebang commands can pick up my 1.8.4 ruby. I don't want to do that, nor do I want others to do it. Any thoughts about how this can be solved? Aslak > Aslak > > > > Cheers > > > Luke > > > > Brandon > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From dchelimsky at gmail.com Wed Nov 8 09:23:33 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 8 Nov 2006 08:23:33 -0600 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <8d961d900611080607w7d06cd2dp930012db9454671b@mail.gmail.com> References: <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> <8d961d900611080607w7d06cd2dp930012db9454671b@mail.gmail.com> Message-ID: <57c63afe0611080623o7d33481ci38ac2a3730045af3@mail.gmail.com> On 11/8/06, aslak hellesoy wrote: > On 11/8/06, aslak hellesoy wrote: > > On 11/8/06, Brandon Keepers wrote: > > > > > > On Nov 8, 2006, at 4:12 AM, Luke Redpath wrote: > > > > > > > Its working for me on 0.7 - are sure it isn't a problem with your > > > > specs and the new release (there are some compatibility issues). Have > > > > you tried running your specs manually? > > > > > > Yes, I've gone through and they are all passing from the command line. > > > > > > > Could it be that you have two rubies installed and that TM is picking > > up a different one than your shell? > > > > That seems to be the case with me. > > > > I have an old ruby (1.8.2) in /usr/bin/ruby that came with OS X. > I also have ruby 1.8.4 in /usr/local/bin/ruby (built myself) > > I have a ~/.bash_login that puts /usr/local/bin early in the path, so > in my everyday coding, I get 1.8.4. > > However, it seems that shebang commands (the RSpec.tmbundle commands > and the spec script) *do not* get the PATH set in ~/.bash_login. This > is explained here: > http://macromates.com/textmate/manual/shell_commands#search_path > > It looks like I have to edit my ~/.MacOSX/environment.plist in order > to fix my PATH so shebang commands can pick up my 1.8.4 ruby. I don't > want to do that, nor do I want others to do it. > > Any thoughts about how this can be solved? How about replacing /usr/bin/ruby w/ a symlink to /usr/local/bin/ruby? > > Aslak > > > Aslak > > > > > > Cheers > > > > Luke > > > > > > Brandon > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From luke at agileevolved.com Wed Nov 8 10:08:09 2006 From: luke at agileevolved.com (Luke Redpath) Date: Wed, 8 Nov 2006 15:08:09 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <8d961d900611080607w7d06cd2dp930012db9454671b@mail.gmail.com> References: <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> <8d961d900611080607w7d06cd2dp930012db9454671b@mail.gmail.com> Message-ID: <12760D77-C8BE-484E-B077-5AB97EFBA221@agileevolved.com> Hmm, you shouldn't have to change anything. I also have the 1.8.2 in / usr/bin that comes with OSX and 1.8.4 in /usr/local/bin and it works fine for me. I'm using /usr/bin/env in the shebang lines so it should be finding it ok. Cheers Luke On 8 Nov 2006, at 14:07, aslak hellesoy wrote: > On 11/8/06, aslak hellesoy wrote: >> On 11/8/06, Brandon Keepers wrote: >>> >>> On Nov 8, 2006, at 4:12 AM, Luke Redpath wrote: >>> >>>> Its working for me on 0.7 - are sure it isn't a problem with your >>>> specs and the new release (there are some compatibility issues). >>>> Have >>>> you tried running your specs manually? >>> >>> Yes, I've gone through and they are all passing from the command >>> line. >>> >> >> Could it be that you have two rubies installed and that TM is picking >> up a different one than your shell? >> >> That seems to be the case with me. >> > > I have an old ruby (1.8.2) in /usr/bin/ruby that came with OS X. > I also have ruby 1.8.4 in /usr/local/bin/ruby (built myself) > > I have a ~/.bash_login that puts /usr/local/bin early in the path, so > in my everyday coding, I get 1.8.4. > > However, it seems that shebang commands (the RSpec.tmbundle commands > and the spec script) *do not* get the PATH set in ~/.bash_login. This > is explained here: > http://macromates.com/textmate/manual/shell_commands#search_path > > It looks like I have to edit my ~/.MacOSX/environment.plist in order > to fix my PATH so shebang commands can pick up my 1.8.4 ruby. I don't > want to do that, nor do I want others to do it. > > Any thoughts about how this can be solved? > > Aslak > >> Aslak >> >>>> Cheers >>>> Luke >>> >>> Brandon >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061108/5e1e7042/attachment-0001.html From noreply at rubyforge.org Wed Nov 8 09:18:24 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 09:18:24 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6555 ] should_have_tag does not match documentation Message-ID: <20061108141824.DC96DA970002@rubyforge.org> Bugs item #6555, was opened at 2006-11-08 09:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: should_have_tag does not match documentation Initial Comment: http://rspec.rubyforge.org/documentation/rails/writing/views.html says should_have_tag takes symbols as arguments. Should_have_tag says otherwise. require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def index() render :inline => '

Hello

'; end end context 'Test Controller' do controller_name :test integrate_views specify 'presents h1' do get :index response.should_have_tag :h1, :content => 'Hello' end end spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:28:in `find_tag': (SyntaxError) SyntaxError in should_have_tag(tag, *opts) * tag should be the name of the tag (like 'div', or 'select' without '<' or '>') * opts should be a Hash of key value pairs from /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:5:in `should_have_tag' from /home/jjw/work/northants/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:22:in `should_have_tag' from ./spec/controllers/test_controller_spec.rb:13:in `__instance_exec0' from ... Whereas strings work fine... response.should_have_tag 'h1', :content => 'Hello' spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller - presents h1 Finished in 0.007113 seconds 1 specification, 0 failures Either the docs or the code should be adjusted. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 14:18 Message: I hadn't taken into account the total run-stop. Excellent point. Raising a separate RFE for that. Thanks, David ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 12:48 Message: Point taken re SyntaxError, but other 'fatal' coding errors such as deferencing nil get caught. However ruby syntax errors in specs (missing 'end' etc) cause the run to fail without executing a spec. This SyntaxError neither causes the run to fail immediately (it can't, of course) nor plays nicely with the usual output. My thinking was that since the spec and the reality differ, it should be reported as usual. It's the coder's job to realise it's the spec that's at fault. That said, it's absolutely no big deal. Regarding symbols yes or no, what does assert_select do? (assert_tag now deprecated) Hmmm, looks like strings. Oh well, my vote would have been for symbols, but I can live without. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 10:32 Message: Can you explain your reasoning? This is a SyntaxError, not an ExpectationNotMet error. Fundamentally different animal IMO. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 10:19 Message: PS: tag_expectations / should_have_tag should really wrap its SyntaxError in something that can be caught by ExpectationNotMetError and handled in the usual way. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 09:38 Message: Should we adjust docs, or support symbols? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 From noreply at rubyforge.org Wed Nov 8 09:38:48 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 09:38:48 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6568 ] Support alternate output formats when running rails tests Message-ID: <20061108143848.52A7B52412DA@rubyforge.org> Feature Requests item #6568, was opened at 2006-11-09 01:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6568&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Simon Harris (haruki_zaemon) Assigned to: Nobody (None) Summary: Support alternate output formats when running rails tests Initial Comment: The default output format (using dots) isn't particular helpful when running as part of a continuous integration process. The most useful seems to be specdoc however there doesn't seem to be a way to enable it's use when running rake spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6568&group_id=797 From noreply at rubyforge.org Wed Nov 8 10:46:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 10:46:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6558 ] integrated views look for template even when redirected Message-ID: <20061108154605.E938D5241358@rubyforge.org> Bugs item #6558, was opened at 2006-11-08 10:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6558&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Jerry West (jjw) >Assigned to: David Chelimsky (dchelimsky) Summary: integrated views look for template even when redirected Initial Comment: require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def go() redirect_to "http://test.host/" end end context 'Test Controller' do controller_name :test integrate_views specify 'redirects as requested' do get :go response.should_be_redirect response.redirect_url.should_be "http://test.host" end end fails: spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller - redirects as requested (FAILED - 1) 1) ActionController::MissingTemplate in 'Test Controller redirects as requested' Missing template /home/jjw/work/northants/config/../app/views/test/go.rhtml /usr/local/lib/site_ruby/1.8/benchmark.rb:300:in `measure' /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/context/controller.rb:46:in `render' /usr/local/lib/site_ruby/1.8/benchmark.rb:300:in `measure' ./spec/controllers/test_controller_spec.rb:18:in `redirects as requested' Finished in 0.013349 seconds 1 specification, 1 failure ------ In the application this is abstracted from, the actual redirect is followed so it looks like an rspec issue. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 15:46 Message: Fixed in trunk revision 1053 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6558&group_id=797 From noreply at rubyforge.org Wed Nov 8 05:15:03 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 05:15:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6558 ] integrated views look for template even when redirected Message-ID: <20061108101503.84CCE5240F3D@rubyforge.org> Bugs item #6558, was opened at 2006-11-08 10:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6558&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: integrated views look for template even when redirected Initial Comment: require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def go() redirect_to "http://test.host/" end end context 'Test Controller' do controller_name :test integrate_views specify 'redirects as requested' do get :go response.should_be_redirect response.redirect_url.should_be "http://test.host" end end fails: spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller - redirects as requested (FAILED - 1) 1) ActionController::MissingTemplate in 'Test Controller redirects as requested' Missing template /home/jjw/work/northants/config/../app/views/test/go.rhtml /usr/local/lib/site_ruby/1.8/benchmark.rb:300:in `measure' /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/context/controller.rb:46:in `render' /usr/local/lib/site_ruby/1.8/benchmark.rb:300:in `measure' ./spec/controllers/test_controller_spec.rb:18:in `redirects as requested' Finished in 0.013349 seconds 1 specification, 1 failure ------ In the application this is abstracted from, the actual redirect is followed so it looks like an rspec issue. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6558&group_id=797 From noreply at rubyforge.org Wed Nov 8 05:26:41 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 05:26:41 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6560 ] controller.session should be available before the action Message-ID: <20061108102642.18B305240F59@rubyforge.org> Feature Requests item #6560, was opened at 2006-11-08 10:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6560&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: controller.session should be available before the action Initial Comment: controller specs expose "session" before and after an action, but "controller.session" is only available afterwards. ['integration', 'isolation'].each do |mode| context "Given a controller spec running in #{mode} mode", :context_type => :controller do controller_name :controller_isolation_spec integrate_views if mode == 'integration' specify "session should be the same object as controller session" do get 'action_with_implied_template' session.should_equal controller.session end specify "session should be the same object before and after the action" do session_before = session get 'action_with_implied_template' session.should_equal session_before end specify "controller.session should NOT be nil before the action" do controller.session.should_not_be nil get 'action_with_implied_template' end specify "controller.session should NOT be nil before the action" do get 'action_with_implied_template' controller.session.should_not_be nil end end end bin/spec vendor/rspec_on_rails/vendor/plugins/rspec/spec/controller_spec_spec.rb -fs Given a controller spec running in integration mode - session should be the same object as controller session - session should be the same object before and after the action - controller.session should NOT be nil before the action (FAILED - 1) - controller.session should NOT be nil before the action Given a controller spec running in isolation mode - session should be the same object as controller session - session should be the same object before and after the action - controller.session should NOT be nil before the action (FAILED - 2) - controller.session should NOT be nil before the action 1) Spec::Expectations::ExpectationNotMetError in 'Given a controller spec running in integration mode controller.session should NOT be nil before the action' nil should not be nil ./vendor/rspec_on_rails/vendor/plugins/rspec/spec/controller_spec_spec.rb:20:in `controller.session should NOT be nil before the action' 2) Spec::Expectations::ExpectationNotMetError in 'Given a controller spec running in isolation mode controller.session should NOT be nil before the action' nil should not be nil ./vendor/rspec_on_rails/vendor/plugins/rspec/spec/controller_spec_spec.rb:20:in `controller.session should NOT be nil before the action' Finished in 0.188877 seconds 8 specifications, 2 failures ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6560&group_id=797 From noreply at rubyforge.org Wed Nov 8 05:53:29 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 05:53:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6547 ] should_be_redirect broken in 0.7.0 Message-ID: <20061108105329.8DE815240FC2@rubyforge.org> Bugs item #6547, was opened at 2006-11-07 19:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: should_be_redirect broken in 0.7.0 Initial Comment: A bunch of specs started failing in 0.7.0. A quick check shows that the following spec fails on .should_be_redirect, which should_be_impossible, since the .should_redirect_to (which I've just added) succeeds. The controller code is a simple redirect_to. context "The HarkController" do controller_name :hark integrate_views fixtures :hark_users specify "should allow Vlad the valid user to log in" do controller.should_redirect_to :action => 'index' post :login, :hark => {:username => "vlad", :password => "atest"} response.should_be_redirect end end ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 10:53 Message: I'm seeing this too. require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def go() redirect_to "http://test.host/" end end context 'Test Controller' do controller_name :test integrate_views specify 'redirects as requested' do get :go rescue nil response.should_be_redirect response.redirect_url.should_be "http://test.host" end end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 02:15 Message: fixed in trunk as of revision 1050 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 22:04 Message: OK - I've got this fixed but I can't seem to get to svn on rubyforge from my current location. I will commit the fix this evening. Thanks Jay. David ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-11-07 20:36 Message: Do I write good bug reports, or what? ::crickets chirping:: The above spec (with appropriate controller code) shows the output: expected response to be redirect but was not /cygdrive/c/dev/src/eclipse/hark/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:10:in `should_be_redirect' It also appears that response.redirect_url is nil after a redirect... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 20:22 Message: What error are you getting? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 From noreply at rubyforge.org Wed Nov 8 06:03:28 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 06:03:28 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6547 ] should_be_redirect broken in 0.7.0 Message-ID: <20061108110329.A84D85240FE8@rubyforge.org> Bugs item #6547, was opened at 2006-11-07 19:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: should_be_redirect broken in 0.7.0 Initial Comment: A bunch of specs started failing in 0.7.0. A quick check shows that the following spec fails on .should_be_redirect, which should_be_impossible, since the .should_redirect_to (which I've just added) succeeds. The controller code is a simple redirect_to. context "The HarkController" do controller_name :hark integrate_views fixtures :hark_users specify "should allow Vlad the valid user to log in" do controller.should_redirect_to :action => 'index' post :login, :hark => {:username => "vlad", :password => "atest"} response.should_be_redirect end end ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 11:03 Message: Sorry, ignore that; I didn't see the fix notice. I'm still at REL_0_7_0 ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 10:53 Message: I'm seeing this too. require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def go() redirect_to "http://test.host/" end end context 'Test Controller' do controller_name :test integrate_views specify 'redirects as requested' do get :go rescue nil response.should_be_redirect response.redirect_url.should_be "http://test.host" end end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 02:15 Message: fixed in trunk as of revision 1050 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 22:04 Message: OK - I've got this fixed but I can't seem to get to svn on rubyforge from my current location. I will commit the fix this evening. Thanks Jay. David ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-11-07 20:36 Message: Do I write good bug reports, or what? ::crickets chirping:: The above spec (with appropriate controller code) shows the output: expected response to be redirect but was not /cygdrive/c/dev/src/eclipse/hark/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:10:in `should_be_redirect' It also appears that response.redirect_url is nil after a redirect... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 20:22 Message: What error are you getting? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6547&group_id=797 From noreply at rubyforge.org Wed Nov 8 05:32:03 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 05:32:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6555 ] should_have_tag does not match documentation Message-ID: <20061108103203.D66985240D8F@rubyforge.org> Bugs item #6555, was opened at 2006-11-08 09:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: should_have_tag does not match documentation Initial Comment: http://rspec.rubyforge.org/documentation/rails/writing/views.html says should_have_tag takes symbols as arguments. Should_have_tag says otherwise. require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def index() render :inline => '

Hello

'; end end context 'Test Controller' do controller_name :test integrate_views specify 'presents h1' do get :index response.should_have_tag :h1, :content => 'Hello' end end spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:28:in `find_tag': (SyntaxError) SyntaxError in should_have_tag(tag, *opts) * tag should be the name of the tag (like 'div', or 'select' without '<' or '>') * opts should be a Hash of key value pairs from /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:5:in `should_have_tag' from /home/jjw/work/northants/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:22:in `should_have_tag' from ./spec/controllers/test_controller_spec.rb:13:in `__instance_exec0' from ... Whereas strings work fine... response.should_have_tag 'h1', :content => 'Hello' spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller - presents h1 Finished in 0.007113 seconds 1 specification, 0 failures Either the docs or the code should be adjusted. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 10:32 Message: Can you explain your reasoning? This is a SyntaxError, not an ExpectationNotMet error. Fundamentally different animal IMO. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 10:19 Message: PS: tag_expectations / should_have_tag should really wrap its SyntaxError in something that can be caught by ExpectationNotMetError and handled in the usual way. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 09:38 Message: Should we adjust docs, or support symbols? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 From noreply at rubyforge.org Wed Nov 8 07:48:58 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 07:48:58 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6555 ] should_have_tag does not match documentation Message-ID: <20061108124858.93F8FA970002@rubyforge.org> Bugs item #6555, was opened at 2006-11-08 09:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: should_have_tag does not match documentation Initial Comment: http://rspec.rubyforge.org/documentation/rails/writing/views.html says should_have_tag takes symbols as arguments. Should_have_tag says otherwise. require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def index() render :inline => '

Hello

'; end end context 'Test Controller' do controller_name :test integrate_views specify 'presents h1' do get :index response.should_have_tag :h1, :content => 'Hello' end end spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:28:in `find_tag': (SyntaxError) SyntaxError in should_have_tag(tag, *opts) * tag should be the name of the tag (like 'div', or 'select' without '<' or '>') * opts should be a Hash of key value pairs from /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:5:in `should_have_tag' from /home/jjw/work/northants/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:22:in `should_have_tag' from ./spec/controllers/test_controller_spec.rb:13:in `__instance_exec0' from ... Whereas strings work fine... response.should_have_tag 'h1', :content => 'Hello' spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller - presents h1 Finished in 0.007113 seconds 1 specification, 0 failures Either the docs or the code should be adjusted. ---------------------------------------------------------------------- >Comment By: Jerry West (jjw) Date: 2006-11-08 12:48 Message: Point taken re SyntaxError, but other 'fatal' coding errors such as deferencing nil get caught. However ruby syntax errors in specs (missing 'end' etc) cause the run to fail without executing a spec. This SyntaxError neither causes the run to fail immediately (it can't, of course) nor plays nicely with the usual output. My thinking was that since the spec and the reality differ, it should be reported as usual. It's the coder's job to realise it's the spec that's at fault. That said, it's absolutely no big deal. Regarding symbols yes or no, what does assert_select do? (assert_tag now deprecated) Hmmm, looks like strings. Oh well, my vote would have been for symbols, but I can live without. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 10:32 Message: Can you explain your reasoning? This is a SyntaxError, not an ExpectationNotMet error. Fundamentally different animal IMO. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 10:19 Message: PS: tag_expectations / should_have_tag should really wrap its SyntaxError in something that can be caught by ExpectationNotMetError and handled in the usual way. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 09:38 Message: Should we adjust docs, or support symbols? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 From noreply at rubyforge.org Wed Nov 8 05:19:10 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 05:19:10 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6555 ] should_have_tag does not match documentation Message-ID: <20061108101910.D29375240F48@rubyforge.org> Bugs item #6555, was opened at 2006-11-08 09:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: should_have_tag does not match documentation Initial Comment: http://rspec.rubyforge.org/documentation/rails/writing/views.html says should_have_tag takes symbols as arguments. Should_have_tag says otherwise. require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def index() render :inline => '

Hello

'; end end context 'Test Controller' do controller_name :test integrate_views specify 'presents h1' do get :index response.should_have_tag :h1, :content => 'Hello' end end spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:28:in `find_tag': (SyntaxError) SyntaxError in should_have_tag(tag, *opts) * tag should be the name of the tag (like 'div', or 'select' without '<' or '>') * opts should be a Hash of key value pairs from /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:5:in `should_have_tag' from /home/jjw/work/northants/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:22:in `should_have_tag' from ./spec/controllers/test_controller_spec.rb:13:in `__instance_exec0' from ... Whereas strings work fine... response.should_have_tag 'h1', :content => 'Hello' spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller - presents h1 Finished in 0.007113 seconds 1 specification, 0 failures Either the docs or the code should be adjusted. ---------------------------------------------------------------------- >Comment By: Jerry West (jjw) Date: 2006-11-08 10:19 Message: PS: tag_expectations / should_have_tag should really wrap its SyntaxError in something that can be caught by ExpectationNotMetError and handled in the usual way. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 09:38 Message: Should we adjust docs, or support symbols? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 From noreply at rubyforge.org Wed Nov 8 09:21:14 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 09:21:14 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6567 ] SyntaxError should not stop entire run Message-ID: <20061108142114.8672B52412B8@rubyforge.org> Bugs item #6567, was opened at 2006-11-08 14:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6567&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: SyntaxError should not stop entire run Initial Comment: In a view spec... specify "should display name" do response.should_have_tag :div, :contents => 'Joe' This throws a SyntaxError because symbols are not supported. However, the syntax error causes a complete test run collapse, rather than being reported in the context of that one spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6567&group_id=797 From noreply at rubyforge.org Wed Nov 8 05:27:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 05:27:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6560 ] controller.session should be available before the action Message-ID: <20061108102757.312F95240E0E@rubyforge.org> Feature Requests item #6560, was opened at 2006-11-08 10:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6560&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: controller.session should be available before the action Initial Comment: controller specs expose "session" before and after an action, but "controller.session" is only available afterwards. ['integration', 'isolation'].each do |mode| context "Given a controller spec running in #{mode} mode", :context_type => :controller do controller_name :controller_isolation_spec integrate_views if mode == 'integration' specify "session should be the same object as controller session" do get 'action_with_implied_template' session.should_equal controller.session end specify "session should be the same object before and after the action" do session_before = session get 'action_with_implied_template' session.should_equal session_before end specify "controller.session should NOT be nil before the action" do controller.session.should_not_be nil get 'action_with_implied_template' end specify "controller.session should NOT be nil before the action" do get 'action_with_implied_template' controller.session.should_not_be nil end end end bin/spec vendor/rspec_on_rails/vendor/plugins/rspec/spec/controller_spec_spec.rb -fs Given a controller spec running in integration mode - session should be the same object as controller session - session should be the same object before and after the action - controller.session should NOT be nil before the action (FAILED - 1) - controller.session should NOT be nil before the action Given a controller spec running in isolation mode - session should be the same object as controller session - session should be the same object before and after the action - controller.session should NOT be nil before the action (FAILED - 2) - controller.session should NOT be nil before the action 1) Spec::Expectations::ExpectationNotMetError in 'Given a controller spec running in integration mode controller.session should NOT be nil before the action' nil should not be nil ./vendor/rspec_on_rails/vendor/plugins/rspec/spec/controller_spec_spec.rb:20:in `controller.session should NOT be nil before the action' 2) Spec::Expectations::ExpectationNotMetError in 'Given a controller spec running in isolation mode controller.session should NOT be nil before the action' nil should not be nil ./vendor/rspec_on_rails/vendor/plugins/rspec/spec/controller_spec_spec.rb:20:in `controller.session should NOT be nil before the action' Finished in 0.188877 seconds 8 specifications, 2 failures ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 10:27 Message: Fixed in revision 1052 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6560&group_id=797 From bkeepers at gmail.com Wed Nov 8 11:25:44 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Wed, 8 Nov 2006 11:25:44 -0500 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> References: <747C3EA3-FFF5-4DB9-87F1-03149C71C43D@gmail.com> <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> Message-ID: <84BAE719-E829-426B-9395-F40F4B0B8A66@gmail.com> On Nov 8, 2006, at 8:38 AM, aslak hellesoy wrote: > On 11/8/06, Brandon Keepers wrote: >> Yes, I've gone through and they are all passing from the command >> line. > > Could it be that you have two rubies installed and that TM is picking > up a different one than your shell? > > That seems to be the case with me. > > Aslak Could be. But what I don't understand is that as soon as I remove the 0.7.0 gem, it works fine. Brandon From noreply at rubyforge.org Wed Nov 8 11:39:24 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 11:39:24 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6555 ] should_have_tag does not match documentation Message-ID: <20061108163925.09B68524145F@rubyforge.org> Bugs item #6555, was opened at 2006-11-08 04:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: should_have_tag does not match documentation Initial Comment: http://rspec.rubyforge.org/documentation/rails/writing/views.html says should_have_tag takes symbols as arguments. Should_have_tag says otherwise. require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def index() render :inline => '

Hello

'; end end context 'Test Controller' do controller_name :test integrate_views specify 'presents h1' do get :index response.should_have_tag :h1, :content => 'Hello' end end spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:28:in `find_tag': (SyntaxError) SyntaxError in should_have_tag(tag, *opts) * tag should be the name of the tag (like 'div', or 'select' without '<' or '>') * opts should be a Hash of key value pairs from /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:5:in `should_have_tag' from /home/jjw/work/northants/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:22:in `should_have_tag' from ./spec/controllers/test_controller_spec.rb:13:in `__instance_exec0' from ... Whereas strings work fine... response.should_have_tag 'h1', :content => 'Hello' spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller - presents h1 Finished in 0.007113 seconds 1 specification, 0 failures Either the docs or the code should be adjusted. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-08 11:39 Message: IMHO, symbols should be supported. Rails allows the use symbols and strings pretty much interchangeably, and in Ruby 1.9, they technically are the same thing. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 09:18 Message: I hadn't taken into account the total run-stop. Excellent point. Raising a separate RFE for that. Thanks, David ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 07:48 Message: Point taken re SyntaxError, but other 'fatal' coding errors such as deferencing nil get caught. However ruby syntax errors in specs (missing 'end' etc) cause the run to fail without executing a spec. This SyntaxError neither causes the run to fail immediately (it can't, of course) nor plays nicely with the usual output. My thinking was that since the spec and the reality differ, it should be reported as usual. It's the coder's job to realise it's the spec that's at fault. That said, it's absolutely no big deal. Regarding symbols yes or no, what does assert_select do? (assert_tag now deprecated) Hmmm, looks like strings. Oh well, my vote would have been for symbols, but I can live without. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 05:32 Message: Can you explain your reasoning? This is a SyntaxError, not an ExpectationNotMet error. Fundamentally different animal IMO. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 05:19 Message: PS: tag_expectations / should_have_tag should really wrap its SyntaxError in something that can be caught by ExpectationNotMetError and handled in the usual way. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 04:38 Message: Should we adjust docs, or support symbols? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 From noreply at rubyforge.org Wed Nov 8 12:45:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 12:45:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6570 ] rSpec on Rails does not clean the test DB inbetween contexts Message-ID: <20061108174513.E1E80A970029@rubyforge.org> Bugs item #6570, was opened at 2006-11-08 18:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6570&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Timm Gebhart (onkeltimm) Assigned to: Nobody (None) Summary: rSpec on Rails does not clean the test DB inbetween contexts Initial Comment: Version: RSpec-0.7.0 (r1039) When I set up a context and load fixtures, those are not removed from the test DB before the next context is run, like this: # This runs fine context "Context with fixtures" do fixtures :tests specify "should have records" do Test.find(:all).should_not_be_empty end end # This fails context "Context w/o fixtures" do specify "should have no records" do Test.should_have(:no).records end end The Test DB should be clean upon entering a context. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6570&group_id=797 From noreply at rubyforge.org Wed Nov 8 11:59:59 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 11:59:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6568 ] Support alternate output formats when running rails tests Message-ID: <20061108165959.9C7B652414F4@rubyforge.org> Feature Requests item #6568, was opened at 2006-11-08 09:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6568&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Simon Harris (haruki_zaemon) Assigned to: Nobody (None) Summary: Support alternate output formats when running rails tests Initial Comment: The default output format (using dots) isn't particular helpful when running as part of a continuous integration process. The most useful seems to be specdoc however there doesn't seem to be a way to enable it's use when running rake spec. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2006-11-08 11:59 Message: I created a basic rake task we use as our default (run as specdoc, with color enabled, and call db:test:prepare prior to the run). It's listed below. require 'spec/rake/spectask' desc "Run all specifications and report the results in spec:doc format" Spec::Rake::SpecTask.new('yournamehere:spec:doc' => 'db:test:prepare') do |t| t.spec_files = FileList[ 'spec/models/**/*_spec.rb', 'spec/controllers/**/*_spec.rb', 'spec/helpers/**/*_spec.rb', 'spec/views/**/*_spec.rb' ] t.spec_opts = ["-cfs"] end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6568&group_id=797 From noreply at rubyforge.org Wed Nov 8 15:48:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 15:48:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6555 ] should_have_tag does not match documentation Message-ID: <20061108204826.7E4CF5240844@rubyforge.org> Bugs item #6555, was opened at 2006-11-08 09:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 Category: expectation module Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Jerry West (jjw) Assigned to: Nobody (None) Summary: should_have_tag does not match documentation Initial Comment: http://rspec.rubyforge.org/documentation/rails/writing/views.html says should_have_tag takes symbols as arguments. Should_have_tag says otherwise. require File.dirname(__FILE__) + '/../spec_helper' class TestController < ActionController::Base def index() render :inline => '

Hello

'; end end context 'Test Controller' do controller_name :test integrate_views specify 'presents h1' do get :index response.should_have_tag :h1, :content => 'Hello' end end spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:28:in `find_tag': (SyntaxError) SyntaxError in should_have_tag(tag, *opts) * tag should be the name of the tag (like 'div', or 'select' without '<' or '>') * opts should be a Hash of key value pairs from /home/jjw/work/northants/vendor/plugins/rspec/lib/spec/rails/tag_expectations.rb:5:in `should_have_tag' from /home/jjw/work/northants/vendor/plugins/rspec/lib/extensions/action_controller/test_response.rb:22:in `should_have_tag' from ./spec/controllers/test_controller_spec.rb:13:in `__instance_exec0' from ... Whereas strings work fine... response.should_have_tag 'h1', :content => 'Hello' spec -fs spec/controllers/test_controller_spec.rb Creating sqlite in memory database... Test Controller - presents h1 Finished in 0.007113 seconds 1 specification, 0 failures Either the docs or the code should be adjusted. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 20:48 Message: Fixed in trunk revision 1057 should_have_tag :now_supports_symbols ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-08 16:39 Message: IMHO, symbols should be supported. Rails allows the use symbols and strings pretty much interchangeably, and in Ruby 1.9, they technically are the same thing. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 14:18 Message: I hadn't taken into account the total run-stop. Excellent point. Raising a separate RFE for that. Thanks, David ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 12:48 Message: Point taken re SyntaxError, but other 'fatal' coding errors such as deferencing nil get caught. However ruby syntax errors in specs (missing 'end' etc) cause the run to fail without executing a spec. This SyntaxError neither causes the run to fail immediately (it can't, of course) nor plays nicely with the usual output. My thinking was that since the spec and the reality differ, it should be reported as usual. It's the coder's job to realise it's the spec that's at fault. That said, it's absolutely no big deal. Regarding symbols yes or no, what does assert_select do? (assert_tag now deprecated) Hmmm, looks like strings. Oh well, my vote would have been for symbols, but I can live without. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 10:32 Message: Can you explain your reasoning? This is a SyntaxError, not an ExpectationNotMet error. Fundamentally different animal IMO. ---------------------------------------------------------------------- Comment By: Jerry West (jjw) Date: 2006-11-08 10:19 Message: PS: tag_expectations / should_have_tag should really wrap its SyntaxError in something that can be caught by ExpectationNotMetError and handled in the usual way. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 09:38 Message: Should we adjust docs, or support symbols? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6555&group_id=797 From noreply at rubyforge.org Wed Nov 8 15:53:47 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 15:53:47 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6178 ] should_return Message-ID: <20061108205347.4A9A2A970003@rubyforge.org> Feature Requests item #6178, was opened at 2006-10-16 11:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: should_return Initial Comment: I'd like to add should_return as an alias for should_equal for lambdas: lambda { expression }.should_return value reads more intuitively than lambda { expression }.should_equal value ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 From noreply at rubyforge.org Wed Nov 8 15:35:51 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 15:35:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6567 ] SyntaxError should not stop entire run Message-ID: <20061108203551.9BB1B5241A3D@rubyforge.org> Bugs item #6567, was opened at 2006-11-08 14:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6567&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: David Chelimsky (dchelimsky) Summary: SyntaxError should not stop entire run Initial Comment: In a view spec... specify "should display name" do response.should_have_tag :div, :contents => 'Joe' This throws a SyntaxError because symbols are not supported. However, the syntax error causes a complete test run collapse, rather than being reported in the context of that one spec. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 20:35 Message: Fixed in trunk revision 1056 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6567&group_id=797 From noreply at rubyforge.org Wed Nov 8 15:50:56 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 15:50:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6027 ] rSpec for Rails fails on helper teardown if no teardown is defined within context Message-ID: <20061108205057.17CED5241A49@rubyforge.org> Bugs item #6027, was opened at 2006-10-05 07:02 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6027&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Jan Wikholm (jwikholm) Assigned to: Nobody (None) Summary: rSpec for Rails fails on helper teardown if no teardown is defined within context Initial Comment: rSpec version 0.6.4 & corresponding rspec_for_rails I had a normal rspec generated by script/generate rspec_model company and had written specs for it. All specs pass otherwise but completely Fail on teardown, which is called from spec/spec_helper.rb(line 23) One example: 1) NoMethodError in 'A company (in general) should be invalid without a name' You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occured while evaluating nil.- ./spec/models/../spec_helper.rb:23:in `teardown' That is same thing is printed for every specify block I have in my specs. After doing a simple: def teardown end in each context block the problem disappeared. It's not hard to fix it yourself, but I feel that defining an empty method for the sake of tests passing is not the way to go. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 20:50 Message: N/A after 0.7 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 10:47 Message: Is this still a problem in 0.7? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6027&group_id=797 From noreply at rubyforge.org Wed Nov 8 15:35:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 15:35:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6570 ] rSpec on Rails does not clean the test DB inbetween contexts Message-ID: <20061108203526.CCFD25241A3D@rubyforge.org> Bugs item #6570, was opened at 2006-11-08 12:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6570&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Timm Gebhart (onkeltimm) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rSpec on Rails does not clean the test DB inbetween contexts Initial Comment: Version: RSpec-0.7.0 (r1039) When I set up a context and load fixtures, those are not removed from the test DB before the next context is run, like this: # This runs fine context "Context with fixtures" do fixtures :tests specify "should have records" do Test.find(:all).should_not_be_empty end end # This fails context "Context w/o fixtures" do specify "should have no records" do Test.should_have(:no).records end end The Test DB should be clean upon entering a context. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 15:35 Message: This is by design in Rails. You would get the same behaviour if you used Test::Unit Just put fixtures :tests in the other context too. Or put it in the spec_helper.rb ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6570&group_id=797 From noreply at rubyforge.org Wed Nov 8 17:24:25 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 17:24:25 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6575 ] Parse error in aliasing the partial mock original method Message-ID: <20061108222425.B8311A970003@rubyforge.org> Bugs item #6575, was opened at 2006-11-08 14:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Parse error in aliasing the partial mock original method Initial Comment: Here is code that caused the error in Rspec 0.7.0. It worked in version 0.6.*: @rake_application = @builder.rake_application = mock("rake_application") ... @rake_application.should_receive(:last_comment=).with("Builds the #{extension} extension") ---- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:116:in `metaclass_eval': (eval):2:in `metaclass_eval': compile error (SyntaxError) (eval):2: parse error, unexpected tIDENTIFIER, expecting $ alias_method :original_exists?_before_proxy, :exists? ^ from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:56:in `define_expected_method' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:45:in `__add' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:26:in `add_message_expectation' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_methods.rb:5:in `should_receive' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:127:in `__instance_exec0' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `instance_exec' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/specification.rb:28:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:45:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:4 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 From noreply at rubyforge.org Wed Nov 8 17:37:25 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 17:37:25 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6178 ] should_return Message-ID: <20061108223725.EFA0FA970003@rubyforge.org> Feature Requests item #6178, was opened at 2006-10-16 07:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: should_return Initial Comment: I'd like to add should_return as an alias for should_equal for lambdas: lambda { expression }.should_return value reads more intuitively than lambda { expression }.should_equal value ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 17:37 Message: I think you mean an alias for should_eql or should == ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 From noreply at rubyforge.org Wed Nov 8 17:53:19 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 17:53:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6577 ] messy mock backtrace when frozen to edge rails Message-ID: <20061108225319.86FDBA970013@rubyforge.org> Bugs item #6577, was opened at 2006-11-08 17:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6577&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: messy mock backtrace when frozen to edge rails Initial Comment: Once I freeze edge rails with rake rails:freeze:edge - even if I freeze it to 1.1.6 - the following app and spec cause a messy backtrace. This does not happen when rails is unfrozen. # app/controllers/test_controller.rb class TestController < ActionController::Base def index tm = TestMock.new tm.foo tm.bar end end class TestMock def foo end end # spec/controllers/one_spec.rb require File.dirname(__FILE__) + '/../spec_helper' context "the test app" do controller_name :test specify "should render the index page" do tm = mock("TestMock") TestMock.stub!(:new).and_return(tm) tm.should_receive(:foo) get 'index' end end # backtrace shown $ spec spec/controllers/one_spec.rb F 1) Spec::Mocks::MockExpectationError in 'the test app should render the index page' Mock 'TestMock' received unexpected message :bar /cygdrive/c/dev/src/eclipse/testapp/config/../app/controllers/test_controller.rb:6:in `index' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `perform_action_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:635:in `call_filter' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:622:in `perform_action_without_benchmark' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/rescue.rb:81:in `perform_action' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `process_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:627:in `process_without_session_management_support' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in `process_without_test' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process' ./spec/controllers/one_spec.rb:10:in `should render the index page' Finished in 0.197 seconds 1 specification, 1 failure ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6577&group_id=797 From noreply at rubyforge.org Wed Nov 8 17:46:54 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 17:46:54 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6178 ] should_return Message-ID: <20061108224654.251FAA970003@rubyforge.org> Feature Requests item #6178, was opened at 2006-10-16 11:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: should_return Initial Comment: I'd like to add should_return as an alias for should_equal for lambdas: lambda { expression }.should_return value reads more intuitively than lambda { expression }.should_equal value ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-08 22:46 Message: Yes. This was initially submitted a while back. So... lambda { expression }.should_return value reads more intuitively than lambda { expression }.should_eql value or lambda { expression }.should == value ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 22:37 Message: I think you mean an alias for should_eql or should == ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 From noreply at rubyforge.org Wed Nov 8 18:11:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 18:11:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6578 ] Integrate SeleniumOnRails with rspec_selenium support Message-ID: <20061108231112.809775241B93@rubyforge.org> Feature Requests item #6578, was opened at 2006-11-08 18:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6578&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: Integrate SeleniumOnRails with rspec_selenium support Initial Comment: The idea of rspec's Selenium support is nice, but SeleniumOnRails provides some great features including the testrunner console, fixture loading, table clearing, etc. I don't know how feasible it is to integrate, since SOR uses Selenium-Core, and rspec currently uses Selenium-RC. But it's my feature request and so I get to ask for it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6578&group_id=797 From noreply at rubyforge.org Wed Nov 8 18:44:25 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 18:44:25 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6577 ] messy mock backtrace when frozen to edge rails Message-ID: <20061108234426.100885241B9A@rubyforge.org> Bugs item #6577, was opened at 2006-11-08 17:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6577&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: messy mock backtrace when frozen to edge rails Initial Comment: Once I freeze edge rails with rake rails:freeze:edge - even if I freeze it to 1.1.6 - the following app and spec cause a messy backtrace. This does not happen when rails is unfrozen. # app/controllers/test_controller.rb class TestController < ActionController::Base def index tm = TestMock.new tm.foo tm.bar end end class TestMock def foo end end # spec/controllers/one_spec.rb require File.dirname(__FILE__) + '/../spec_helper' context "the test app" do controller_name :test specify "should render the index page" do tm = mock("TestMock") TestMock.stub!(:new).and_return(tm) tm.should_receive(:foo) get 'index' end end # backtrace shown $ spec spec/controllers/one_spec.rb F 1) Spec::Mocks::MockExpectationError in 'the test app should render the index page' Mock 'TestMock' received unexpected message :bar /cygdrive/c/dev/src/eclipse/testapp/config/../app/controllers/test_controller.rb:6:in `index' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `perform_action_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:635:in `call_filter' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:622:in `perform_action_without_benchmark' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/rescue.rb:81:in `perform_action' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `process_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:627:in `process_without_session_management_support' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in `process_without_test' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process' ./spec/controllers/one_spec.rb:10:in `should render the index page' Finished in 0.197 seconds 1 specification, 1 failure ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 18:44 Message: I think this can be fixed with a tweak in backtrace_tweaker.rb Could you try to create a patch since you already have the environment up? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6577&group_id=797 From noreply at rubyforge.org Wed Nov 8 20:25:18 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 20:25:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6577 ] messy mock backtrace when frozen to edge rails Message-ID: <20061109012518.64D565241BBD@rubyforge.org> Bugs item #6577, was opened at 2006-11-08 17:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6577&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: messy mock backtrace when frozen to edge rails Initial Comment: Once I freeze edge rails with rake rails:freeze:edge - even if I freeze it to 1.1.6 - the following app and spec cause a messy backtrace. This does not happen when rails is unfrozen. # app/controllers/test_controller.rb class TestController < ActionController::Base def index tm = TestMock.new tm.foo tm.bar end end class TestMock def foo end end # spec/controllers/one_spec.rb require File.dirname(__FILE__) + '/../spec_helper' context "the test app" do controller_name :test specify "should render the index page" do tm = mock("TestMock") TestMock.stub!(:new).and_return(tm) tm.should_receive(:foo) get 'index' end end # backtrace shown $ spec spec/controllers/one_spec.rb F 1) Spec::Mocks::MockExpectationError in 'the test app should render the index page' Mock 'TestMock' received unexpected message :bar /cygdrive/c/dev/src/eclipse/testapp/config/../app/controllers/test_controller.rb:6:in `index' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `perform_action_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:635:in `call_filter' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:622:in `perform_action_without_benchmark' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/rescue.rb:81:in `perform_action' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `process_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:627:in `process_without_session_management_support' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in `process_without_test' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process' ./spec/controllers/one_spec.rb:10:in `should render the index page' Finished in 0.197 seconds 1 specification, 1 failure ---------------------------------------------------------------------- >Comment By: Jay Levitt (jaylev) Date: 2006-11-08 20:25 Message: Easier done than said! ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 18:44 Message: I think this can be fixed with a tweak in backtrace_tweaker.rb Could you try to create a patch since you already have the environment up? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6577&group_id=797 From noreply at rubyforge.org Wed Nov 8 18:48:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 18:48:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6575 ] Parse error in aliasing the partial mock original method Message-ID: <20061108234851.0EF665241B98@rubyforge.org> Bugs item #6575, was opened at 2006-11-08 17:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Parse error in aliasing the partial mock original method Initial Comment: Here is code that caused the error in Rspec 0.7.0. It worked in version 0.6.*: @rake_application = @builder.rake_application = mock("rake_application") ... @rake_application.should_receive(:last_comment=).with("Builds the #{extension} extension") ---- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:116:in `metaclass_eval': (eval):2:in `metaclass_eval': compile error (SyntaxError) (eval):2: parse error, unexpected tIDENTIFIER, expecting $ alias_method :original_exists?_before_proxy, :exists? ^ from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:56:in `define_expected_method' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:45:in `__add' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:26:in `add_message_expectation' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_methods.rb:5:in `should_receive' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:127:in `__instance_exec0' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `instance_exec' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/specification.rb:28:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:45:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:4 ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 18:48 Message: Fixed in r1059 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-08 18:23 Message: Here is a quick fix I put into my spec_helper.rb module Spec module Mocks class MockHandler def __pre_proxied_method_name method_name "original_#{method_name.to_s.delete('!').delete('=').delete('?').delete('[').delete('\]')}_before_proxy" end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 From noreply at rubyforge.org Wed Nov 8 18:23:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 8 Nov 2006 18:23:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6575 ] Parse error in aliasing the partial mock original method Message-ID: <20061108232305.64089A970017@rubyforge.org> Bugs item #6575, was opened at 2006-11-08 14:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Parse error in aliasing the partial mock original method Initial Comment: Here is code that caused the error in Rspec 0.7.0. It worked in version 0.6.*: @rake_application = @builder.rake_application = mock("rake_application") ... @rake_application.should_receive(:last_comment=).with("Builds the #{extension} extension") ---- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:116:in `metaclass_eval': (eval):2:in `metaclass_eval': compile error (SyntaxError) (eval):2: parse error, unexpected tIDENTIFIER, expecting $ alias_method :original_exists?_before_proxy, :exists? ^ from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:56:in `define_expected_method' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:45:in `__add' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:26:in `add_message_expectation' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_methods.rb:5:in `should_receive' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:127:in `__instance_exec0' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `instance_exec' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/specification.rb:28:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:45:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:4 ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2006-11-08 15:23 Message: Here is a quick fix I put into my spec_helper.rb module Spec module Mocks class MockHandler def __pre_proxied_method_name method_name "original_#{method_name.to_s.delete('!').delete('=').delete('?').delete('[').delete('\]')}_before_proxy" end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 From aslak.hellesoy at gmail.com Wed Nov 8 23:33:38 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 9 Nov 2006 05:33:38 +0100 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <84BAE719-E829-426B-9395-F40F4B0B8A66@gmail.com> References: <8d961d900611040117n264d1e07keda4c6990407a25@mail.gmail.com> <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> <84BAE719-E829-426B-9395-F40F4B0B8A66@gmail.com> Message-ID: <8d961d900611082033l51454023h685a553cb983499@mail.gmail.com> Attached is a (big) patch of RSpec.tmbundle that leverages RSpec core's HmlFormatter. The code is a lot simpler now. D Commands/Run All Specifications.tmCommand M Commands/Run Focussed Specification.tmCommand A Commands/Run Specifications (Normal).tmCommand M Commands/Run Specifications (SpecDoc).tmCommand A Support/Rakefile A Support/lib/text_mate_formatter.rb M Support/lib/spec_mate.rb D Support/spec/spec_runner_spec.rb M Support/spec/spec_scanner_spec.rb D Support/spec/spec_command_spec.rb M Support/spec/fixtures/example_failing_spec.rb D Support/spec/fixtures/example_passing_spec.rb A Support/spec/spec_mate_spec.rb Give it a whirl and see what you think Aslak -------------- next part -------------- A non-text attachment was scrubbed... Name: running_with_text_mate_formatter.patch Type: application/octet-stream Size: 19950 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061109/00583b9b/attachment-0001.obj From aslak.hellesoy at gmail.com Wed Nov 8 23:46:52 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 9 Nov 2006 05:46:52 +0100 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <8d961d900611082033l51454023h685a553cb983499@mail.gmail.com> References: <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> <84BAE719-E829-426B-9395-F40F4B0B8A66@gmail.com> <8d961d900611082033l51454023h685a553cb983499@mail.gmail.com> Message-ID: <8d961d900611082046v7c66a365h3c811ecab106859c@mail.gmail.com> On 11/9/06, aslak hellesoy wrote: > Attached is a (big) patch of RSpec.tmbundle that leverages RSpec > core's HmlFormatter. > The code is a lot simpler now. > P.S. It only works with RSpec from svn r1069 Aslak > D Commands/Run All Specifications.tmCommand > M Commands/Run Focussed Specification.tmCommand > A Commands/Run Specifications (Normal).tmCommand > M Commands/Run Specifications (SpecDoc).tmCommand > A Support/Rakefile > A Support/lib/text_mate_formatter.rb > M Support/lib/spec_mate.rb > D Support/spec/spec_runner_spec.rb > M Support/spec/spec_scanner_spec.rb > D Support/spec/spec_command_spec.rb > M Support/spec/fixtures/example_failing_spec.rb > D Support/spec/fixtures/example_passing_spec.rb > A Support/spec/spec_mate_spec.rb > > Give it a whirl and see what you think > > Aslak > > > From luke at agileevolved.com Thu Nov 9 05:10:06 2006 From: luke at agileevolved.com (Luke Redpath) Date: Thu, 9 Nov 2006 10:10:06 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <8d961d900611082046v7c66a365h3c811ecab106859c@mail.gmail.com> References: <6FCCCD27-5D53-4230-A4E0-0F064E071F86@agileevolved.com> <335CC741-A413-41F9-9170-1309DB760061@gmail.com> <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> <84BAE719-E829-426B-9395-F40F4B0B8A66@gmail.com> <8d961d900611082033l51454023h685a553cb983499@mail.gmail.com> <8d961d900611082046v7c66a365h3c811ecab106859c@mail.gmail.com> Message-ID: <90DC39CC-6144-4BD3-9F55-C309A6D9642A@agileevolved.com> Looks great. I think the HTML formatting could be a bit prettier (but thats easily tweaked) and I'd like to hold off on committing until 0.7.1 is released (any ETAs on that?), otherwise it will be going in. One bug I noticed is that instead of displaying the context name it says 'Spec::Rails::ContextFactory' instead. Cheers Luke On 9 Nov 2006, at 04:46, aslak hellesoy wrote: > On 11/9/06, aslak hellesoy wrote: >> Attached is a (big) patch of RSpec.tmbundle that leverages RSpec >> core's HmlFormatter. >> The code is a lot simpler now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061109/a0e0dca8/attachment.html From aslak.hellesoy at gmail.com Thu Nov 9 07:28:07 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 9 Nov 2006 13:28:07 +0100 Subject: [rspec-devel] RSpec on JRuby Message-ID: <8d961d900611090428kf074d3eqf2831169e41b2291@mail.gmail.com> I thought I'd try out how RSpec works on JRuby. I installed JRuby and the diff-lcs gem as described here: http://www.headius.com/jrubywiki/index.php/Getting_Started svn co svn://svn.codehaus.org/jruby/trunk/jruby jruby cd jruby ant jar export JRUBY_HOME=$PATH:`pwd` export PATH=$PATH:$JRUBY_HOME/bin # Doenload to Desktop: http://rubyforge.org/frs/download.php/1703/diff-lcs-1.1.2.gem # couldn't get to work with curl bin/gem install ~/Desktop/diff-lcs-1.1.2.gem.tar I started with RSpec's examples - standing in the RSpec root directory: jruby -Ilib bin/spec examples ........................................ Finished in 0.232 seconds 40 specifications, 0 failures Yay! A little bit harder: jruby -Ilib bin/spec failing_examples/diffing_spec.rb --diff FF 1) NoMethodError in 'Running specs with --diff should print diff of different strings' private method 'raise' called for Kernel:Module failing_examples/diffing_spec.rb:13:in `should print diff of different strings' 2) NoMethodError in 'Running specs with --diff should print diff of different objects' pretty representation' private method 'raise' called for Kernel:Module failing_examples/diffing_spec.rb:34:in `should print diff of different objects' pretty representation' Finished in 0.032 seconds Ouch! :-) And running RSpec's dogfood: jruby -Ilib bin/spec spec .....F.FF..F..FFF.......F.F.F.F.FFFFF...FFFFF...F.F....FF....FF.F....FFFFFFFFF.....FF..FFF.F.FFF.......F.F.F.FFFFF.....FFFFF.....F.FException in thread "main" java.lang.ClassCastException: org.jruby.RubyNil at org.jruby.Ruby.printError(Ruby.java:800) at org.jruby.Main.runInterpreter(Main.java:166) at org.jruby.Main.run(Main.java:111) at org.jruby.Main.main(Main.java:86) Not bad for a first try. I'm not sure whether it's failing because of Ruby 1.8.5 (that's what JRuby trunk is based on) or JRuby itself. Maybe building RSpec could be a nice acceptance test for JRuby? Has anyone tried to run RSpec with (standard) Ruby 1.8.5? Aslak From aslak.hellesoy at gmail.com Thu Nov 9 07:32:18 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 9 Nov 2006 13:32:18 +0100 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <90DC39CC-6144-4BD3-9F55-C309A6D9642A@agileevolved.com> References: <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> <84BAE719-E829-426B-9395-F40F4B0B8A66@gmail.com> <8d961d900611082033l51454023h685a553cb983499@mail.gmail.com> <8d961d900611082046v7c66a365h3c811ecab106859c@mail.gmail.com> <90DC39CC-6144-4BD3-9F55-C309A6D9642A@agileevolved.com> Message-ID: <8d961d900611090432y526194b8lc2064a73e7b6f129@mail.gmail.com> On 11/9/06, Luke Redpath wrote: > > Looks great. I think the HTML formatting could be a bit prettier (but thats > easily tweaked) Oh definitely. The blue on red is awful. And the general fonts/layout (in RSpec core) can be improved too. Feel free to improve html_formatted.html (and the HtmlFormatter class) > and I'd like to hold off on committing until 0.7.1 is > released (any ETAs on that?), otherwise it will be going in. > No ETA AFAIK, but I see no reason to delay it. > > One bug I noticed is that instead of displaying the context name it says > 'Spec::Rails::ContextFactory' instead. > Really? Got some HTML? Aslak > Cheers > Luke > > On 9 Nov 2006, at 04:46, aslak hellesoy wrote: > > On 11/9/06, aslak hellesoy wrote: > Attached is a (big) patch of RSpec.tmbundle that leverages RSpec > core's HmlFormatter. > The code is a lot simpler now. > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From luke at agileevolved.com Thu Nov 9 08:49:03 2006 From: luke at agileevolved.com (Luke Redpath) Date: Thu, 9 Nov 2006 13:49:03 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <8d961d900611090432y526194b8lc2064a73e7b6f129@mail.gmail.com> References: <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> <84BAE719-E829-426B-9395-F40F4B0B8A66@gmail.com> <8d961d900611082033l51454023h685a553cb983499@mail.gmail.com> <8d961d900611082046v7c66a365h3c811ecab106859c@mail.gmail.com> <90DC39CC-6144-4BD3-9F55-C309A6D9642A@agileevolved.com> <8d961d900611090432y526194b8lc2064a73e7b6f129@mail.gmail.com> Message-ID: On 9 Nov 2006, at 12:32, aslak hellesoy wrote: > > Oh definitely. The blue on red is awful. And the general fonts/layout > (in RSpec core) can be improved too. Feel free to improve > html_formatted.html (and the HtmlFormatter class) I'll have a bash! > > No ETA AFAIK, but I see no reason to delay it. Maybe its best to wait a week or so in case any other major bugs get found? > Really? Got some HTML? Nope (I've reverted back to 0.7 for now) but the problem appears to be elsewhere as I can reproduce on the command line with the specdoc format: --- spec --format specdoc user_spec.rb --- outputs: --- Spec::Rails::ContextFactory - should be authenticatable - should be valid with valid attributes - should be invalid without an email - should be invalid without a password - should be invalid if password is less than 5 characters in length - should be invalid without a unique email - should be invalid without a matching password confirmation Spec::Rails::ContextFactory - should not be enabled - should not be activated - should have no credit cards - should have no sales - should have no purchases Spec::Rails::ContextFactory - should be authenticatable by its email address - should not be activated - should not be enabled - should have a generated activation key - can be activated with the correct activation key - should be enabled after successful activation Spec::Rails::ContextFactory - should return nil if given an invalid activation key Spec::Rails::ContextFactory - should have a new randomly generated password - should not be able to login with old password after save - should be able to log in with new password after save I think the bug is in the Rails plugin as I cannot reproduce this with specs for non-Rails apps - they work fine. Cheers Luke > > Aslak > >> Cheers >> Luke >> >> On 9 Nov 2006, at 04:46, aslak hellesoy wrote: >> >> On 11/9/06, aslak hellesoy wrote: >> Attached is a (big) patch of RSpec.tmbundle that leverages RSpec >> core's HmlFormatter. >> The code is a lot simpler now. >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061109/0d936a17/attachment-0001.html From nicksieger at gmail.com Thu Nov 9 11:29:54 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Thu, 9 Nov 2006 10:29:54 -0600 Subject: [rspec-devel] RSpec on JRuby In-Reply-To: <8d961d900611090428kf074d3eqf2831169e41b2291@mail.gmail.com> References: <8d961d900611090428kf074d3eqf2831169e41b2291@mail.gmail.com> Message-ID: On 11/9/06, aslak hellesoy wrote: > > I thought I'd try out how RSpec works on JRuby. [...] > Not bad for a first try. I'm not sure whether it's failing because of > Ruby 1.8.5 (that's what JRuby trunk is based on) or JRuby itself. > Maybe building RSpec could be a nice acceptance test for JRuby? That's a great idea, I'll bring it up on the jruby and rubytests lists. Pat Eyler has a project called legion where he's using tests from Ruby projects as a yardstick of how complete a Ruby implementation is. RSpec could certainly be added to it. The fact that RSpec specs itself is pretty cool and should add a new dimension to those tests, I would think. JRuby is based on 1.8.x -- I wouldn't say that it's tracking the most recent changes in 1.8.5 so closely that 1.8.5 compatibility issues are very likely to be the culprit. Cheers, /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061109/769879c7/attachment.html From aslak.hellesoy at gmail.com Thu Nov 9 11:43:57 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 9 Nov 2006 17:43:57 +0100 Subject: [rspec-devel] RSpec on JRuby In-Reply-To: References: <8d961d900611090428kf074d3eqf2831169e41b2291@mail.gmail.com> Message-ID: <8d961d900611090843k334bfddfgff8325d4fb44bb1a@mail.gmail.com> On 11/9/06, Nick Sieger wrote: > On 11/9/06, aslak hellesoy wrote: > > I thought I'd try out how RSpec works on JRuby. > > [...] > > > > > Not bad for a first try. I'm not sure whether it's failing because of > > Ruby 1.8.5 (that's what JRuby trunk is based on) or JRuby itself. > > Maybe building RSpec could be a nice acceptance test for JRuby? > > That's a great idea, I'll bring it up on the jruby and rubytests lists. Pat > Eyler has a project called legion where he's using tests from Ruby projects > as a yardstick of how complete a Ruby implementation is. RSpec could > certainly be added to it. The fact that RSpec specs itself is pretty cool > and should add a new dimension to those tests, I would think. > > JRuby is based on 1.8.x -- I wouldn't say that it's tracking the most recent > changes in 1.8.5 so closely that 1.8.5 compatibility issues are very likely > to be the culprit. > If you talk to them, please tell them that I think I found the reason for most of the errors: The following code does not behave consistently with C Ruby in JRuby trunk/HEAD: Kernel.raise "Hello" # => NoMethodError: private method 'raise' called for Kernel:Module In Ruby it raises RuntimeError: Lala (I was unable to subscribe to dev at jruby.codehaus.org) > Cheers, > /Nick > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From noreply at rubyforge.org Thu Nov 9 05:42:33 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 05:42:33 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6570 ] rSpec on Rails does not clean the test DB inbetween contexts Message-ID: <20061109104233.E5D6AA97000B@rubyforge.org> Bugs item #6570, was opened at 2006-11-08 18:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6570&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Timm Gebhart (onkeltimm) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rSpec on Rails does not clean the test DB inbetween contexts Initial Comment: Version: RSpec-0.7.0 (r1039) When I set up a context and load fixtures, those are not removed from the test DB before the next context is run, like this: # This runs fine context "Context with fixtures" do fixtures :tests specify "should have records" do Test.find(:all).should_not_be_empty end end # This fails context "Context w/o fixtures" do specify "should have no records" do Test.should_have(:no).records end end The Test DB should be clean upon entering a context. ---------------------------------------------------------------------- >Comment By: Timm Gebhart (onkeltimm) Date: 2006-11-09 11:42 Message: I might be misunderstanding, but this does not make sense to me at all. The reason there is a test database in the first place is that it gives you a reliable state at the beginning of each context/test/spec. To me, this implies that when i do not load fixtures at all, I get an empty DB (and this IS a boundary condition, and I have to test it). Also between different model's *_spec.rb files, the DB is never cleaned. How can I ensure I have a DB that is clean except for the structure in a contest/test/spec? I'd be happy to be enlightened, but this does seem like a design error to me. Wonder if I should bring this up in Rails core, what do you think? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 21:35 Message: This is by design in Rails. You would get the same behaviour if you used Test::Unit Just put fixtures :tests in the other context too. Or put it in the spec_helper.rb ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6570&group_id=797 From noreply at rubyforge.org Thu Nov 9 03:51:22 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 03:51:22 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6265 ] should_raise should accept an Exception object Message-ID: <20061109085123.77A325240DF0@rubyforge.org> Feature Requests item #6265, was opened at 2006-10-21 22:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 Category: mock module Group: None Status: Closed Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: should_raise should accept an Exception object Initial Comment: So I can pass it an exception object with the message (or anything else) set on it. ---------------------------------------------------------------------- >Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-09 01:51 Message: OK, here's a failing spec which illustrates what I'm talking about. Basically, I want to provide my own pre-created exception to be thrown, with a specified error message. require 'rubygems' require 'spec' context "a mock" do specify "should allow a pre-created exception to be raised" do error_message = "msg" e = RuntimeError.new(error_message) errormock = mock("Mock") errormock.should_receive(:method).and_raise(e) errmsg = nil begin errormock.method rescue RuntimeError => e errmsg = e.message end errmsg.should_equal(error_message) end end ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-10-23 23:51 Message: Yes, I meant "and_raise", it was a typo. I will try the Proc#should_raise and see if that works. Thanks, Chad ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-22 05:42 Message: I'm a little confused. You categorised this RFE in the mock module. RSpec mocks don't have a sould_raise method, but an and_raise method (which allows you to pass in an exception) http://rspec.rubyforge.org/documentation/mocks.html http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/mocks/mock_spec.rb?revision=931&root=rspec Or perhaps you're talking about the Proc#should_raise method? It also allows you to pass an exception object: http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/expectations/should/should_raise_spec.rb?root=rspec&view=co http://rspec.rubyforge.org/documentation/expectations.html If this doesn't work for you, please submit a failing spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 From noreply at rubyforge.org Thu Nov 9 08:37:40 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 08:37:40 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061109133740.CE3DE52413F4@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-30 02:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:37 Message: Won't fix. Creeping featuritis. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-01 02:06 Message: Just to chime in, I don't see a reason for something like this. The whole point of BDD and RSpec is to guide us along a better path of development. If you're smart enough to know when to stray from the path, you're smart enough to use your editor's TODO tool (or write a simple script to do it for you). ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-30 20:46 Message: which leaves us to: # todo specify "something that needs doing" and then use my editor to find the todos. all good text editors have that built-in. why should we reimplement this in rspec? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 20:30 Message: todo - I like that also. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-30 19:18 Message: how about todo "something that needs doing" instead of implement "something that needs doing" because implement is really just a todo - isn't it? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-10-30 08:33 Message: +1 for implement ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-30 08:07 Message: The suggested "implement" placeholder would be pretty cool. I have generally started fleshing out specs on rails based projects by flurrying through the model specs spewing out minimal specify statements for the limited things I know about them. Usually just throwing in violations as I'm flying through. Then I start running the specs and going through adding the contraints and going for green. It's a pretty noisy "todo" list when running the specs to find the placeholders. It'd be nice to have a more aesthetically pleasing "todo list" to work from. :) But I concur that being able to turn a real spec yellow probably isn't the behavior we're looking for. rake spec:implement or something that produced a spec:doc like format or something would be pretty nice. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 07:12 Message: FWIW - Irony of ironies, there is currently an abhorrently commented out spec in the trunk. And *I'm* the one who put it there. Even still, I'd rather do so and feel a little dirty about it than have the tool make me feel clean. Or even just a little yellow. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 04:57 Message: Writing an entire specify block before a feature is implemented is not what BDD is about. It goes against the red/green/refactor cycle of TDD, which sits at the heart of BDD. For what it's worth, there is a similar feature in NUnit. I don't believe that I've ever seen it used to allow tests to be ignored in advance of implementation. I've only ever seen it used to ignore existing tests that had been passing and were now failing. Worse, I've seen this cause yellow to become the new green (i.e. an acceptable state for commits and sometimes even releases). Absolutely vile. That said, making decisions about behaviour in advance of implementation is very much aligned w/ BDD, even TDD. What would you think about something like this: implement "should support placeholders for yet to exist specs" This would not accept a block. In fact it would raise if you try to give it one. This way you could write placeholders for specs you know you want, but not allow you to put any code in them. Then there could be a command line option that allows you to report on yet-to-implement specs. Of course, if you insist on violating one of the most basic principles of BDD, you can write up your spec code and comment it out. The commented code would be in a logical place, but the tool would not be condoning the practice. Thoughts? David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-30 02:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From noreply at rubyforge.org Thu Nov 9 09:11:21 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 09:11:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6471 ] Easy way to spec routes Message-ID: <20061109141121.9EADB524141A@rubyforge.org> Patches item #6471, was opened at 2006-11-03 13:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6471&group_id=797 >Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Easy way to spec routes Initial Comment: I'd like to specify that my routes are generating correctly, as shown below: context "The EventsController" do controller_name :events specify "should be a EventsController" do controller.should_be_an_instance_of EventsController end specify "should map { :controller => 'events', :action => 'index' } to /events" do routing(:controller => "events", :action => "index").should_equal "/events" end specify "should map { :controller => 'events', :action => 'show', :id => 1 } to /events/1" do routing(:controller => "events", :action => "show", :id => 1).should_equal "/events/1" end specify "should map { :controller => 'events', :action => 'edit', :id => 1 } to /events/1;edit" do routing(:controller => "events", :action => "edit", :id => 1).should_equal "/events/1;edit" end specify "should map { :controller => 'events', :action => 'new' } to /events/new" do routing(:controller => "events", :action => "new").should_equal "/events/new" end end I made it work by adding the following method to Spec::Runner::ContextEval::InstanceMethods def routing(options) # Load routes.rb if it hasn't been loaded ActionController::Routing::Routes.reload if ActionController::Routing::Routes.empty? ActionController::Routing::Routes.generate(options) end Sorry I don't have any specs for it..the rspec_rails 0.6.4 plugin doesn't have any specs to add to. Not sure how robust this will be (it only uses a tiny part of the code from Rails' assert_routing), but so far it's worked for all of my basic routes. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 09:11 Message: I'm moving this to a patch. This patch must be applied in order to get rspec_resource to work (http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797) I'm not applying it yet since there are no specs, and it doesn't seem to work with Rails 1.1.6 (the latest release as of this writing) ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-04 23:20 Message: re: testing rails. It's basically the same as when you have validations set up in your model. You test to make sure those are working, right? It's certainly behavior, even if Rails takes care of the hard part. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-11-04 21:06 Message: There's also the opposite operation of recognising a url using the routing patterns... also produces matched params hash, plus an "extras" hash. Like specify "should recognise /events/1;edit as { :controller => 'events', :action => 'edit', :id => 1 }" do route_recognise("/events/1;edit").should_equal(:controller => "events", :action => "edit", :id => 1) end This kind of expectation might be mooted by integration speccing. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-11-04 21:01 Message: I had a look at this too a while back. I think there needs to be a second argument to #routing through which you can send the "extra" parameters. I was assuming that these are arbitrary parameters which don't fit into the rest of the route pattern, and are generated out as the query of the url. Does that sound right? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-04 16:38 Message: This is very useful for verifying custom routes (config/routes.rb) , which is rather common in Rails apps. It's not testing rails, it's testing *your* routes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-04 15:02 Message: This seems like you're testing rails as opposed to specifying the behaviour of your code. Am I missing something? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6471&group_id=797 From noreply at rubyforge.org Thu Nov 9 11:35:00 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 11:35:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator Message-ID: <20061109163500.BDE0CA97003E@rubyforge.org> Feature Requests item #6098, was opened at 2006-10-11 04:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Make scaffold_resource generator Initial Comment: In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-09 09:35 Message: I applied the patch. Sorry about the routing method error...I completely forgot I had that in there. I saw your comment in http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6471&group_id=797 that it doesn't work in 1.1.6. What would you like me to do for this plugin? Should I move the routing method into the plugin itself? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 07:17 Message: I'm attaching a patch with some small improvements: should_eql and correct use of controller_class_name ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 06:41 Message: Looks like routing is defined in this "patch": http://rubyforge.org/tracker/index.php?func=detail&aid=6471&group_id=797&atid=3152 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 06:34 Message: I tried this with RSpec's demo app (vendor/rspec_on_rails) - I created an account resource. The following code is failing: NoMethodError in 'The accountsController should map { :controller => 'accounts', :action => 'show', :id => 1 } to /accounts/1' undefined method `routing' for #<#:0x3b2d680> Where is this routing method defined? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-04 09:49 Message: My plugin at http://svn.flpr.org/public/plugins/rspec_resource_generator/ handles that. I removed the forked code, so the only template now is the controller_spec. Everything else is pulled from the standard Rails generators, and the rspec_model generator for the model spec. Anything else that should be done with that? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-04 02:28 Message: We should *not* fork/copy Rails code. Reuse all the existing templates, swap the test generation with spec generation (our own template). See the implementation of rspec_model and rspec_controller generators. ---------------------------------------------------------------------- Comment By: Jeff Dean (jefdean) Date: 2006-10-30 01:09 Message: I've written an rspec_scaffold_resource generator and I'm just waiting to here back on a few questions about directory changes in trunk before submitting the patch - Jeff Dean ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 From noreply at rubyforge.org Thu Nov 9 08:41:46 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 08:41:46 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator Message-ID: <20061109134146.46D615241401@rubyforge.org> Feature Requests item #6098, was opened at 2006-10-11 06:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Make scaffold_resource generator Initial Comment: In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:41 Message: Looks like routing is defined in this "patch": http://rubyforge.org/tracker/index.php?func=detail&aid=6471&group_id=797&atid=3152 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:34 Message: I tried this with RSpec's demo app (vendor/rspec_on_rails) - I created an account resource. The following code is failing: NoMethodError in 'The accountsController should map { :controller => 'accounts', :action => 'show', :id => 1 } to /accounts/1' undefined method `routing' for #<#:0x3b2d680> Where is this routing method defined? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-04 11:49 Message: My plugin at http://svn.flpr.org/public/plugins/rspec_resource_generator/ handles that. I removed the forked code, so the only template now is the controller_spec. Everything else is pulled from the standard Rails generators, and the rspec_model generator for the model spec. Anything else that should be done with that? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-04 04:28 Message: We should *not* fork/copy Rails code. Reuse all the existing templates, swap the test generation with spec generation (our own template). See the implementation of rspec_model and rspec_controller generators. ---------------------------------------------------------------------- Comment By: Jeff Dean (jefdean) Date: 2006-10-30 03:09 Message: I've written an rspec_scaffold_resource generator and I'm just waiting to here back on a few questions about directory changes in trunk before submitting the patch - Jeff Dean ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 From noreply at rubyforge.org Thu Nov 9 11:54:59 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 11:54:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator Message-ID: <20061109165500.EC1CFA97001C@rubyforge.org> Feature Requests item #6098, was opened at 2006-10-11 06:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Make scaffold_resource generator Initial Comment: In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 11:54 Message: I think the routing patch should be applied separately in spec/rails. We have to make it work with both 1.1.6 and Edge Rails. This brings up another issue - our build system needs to be able to run all spec/rails specs several times, typically once for the latest Rails release and once for edge. -Possibly with a mechanism to differentiate what's being run depending on the Rails version. I think the most pragmatic way to verify that this (and other generators) is working is to have the rake script (bootstrap_rspec.rake) execute the various generators before specs are run. And then delete the generated files afterwards (or maybe right before they're generated). This would require that we change the templates - right now they fail on purpose with "not enough specs". We should be able to generate stuff and have all specs pass. If you could help with any of this it would be fabulous! ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-09 11:35 Message: I applied the patch. Sorry about the routing method error...I completely forgot I had that in there. I saw your comment in http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6471&group_id=797 that it doesn't work in 1.1.6. What would you like me to do for this plugin? Should I move the routing method into the plugin itself? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 09:17 Message: I'm attaching a patch with some small improvements: should_eql and correct use of controller_class_name ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:41 Message: Looks like routing is defined in this "patch": http://rubyforge.org/tracker/index.php?func=detail&aid=6471&group_id=797&atid=3152 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:34 Message: I tried this with RSpec's demo app (vendor/rspec_on_rails) - I created an account resource. The following code is failing: NoMethodError in 'The accountsController should map { :controller => 'accounts', :action => 'show', :id => 1 } to /accounts/1' undefined method `routing' for #<#:0x3b2d680> Where is this routing method defined? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-04 11:49 Message: My plugin at http://svn.flpr.org/public/plugins/rspec_resource_generator/ handles that. I removed the forked code, so the only template now is the controller_spec. Everything else is pulled from the standard Rails generators, and the rspec_model generator for the model spec. Anything else that should be done with that? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-04 04:28 Message: We should *not* fork/copy Rails code. Reuse all the existing templates, swap the test generation with spec generation (our own template). See the implementation of rspec_model and rspec_controller generators. ---------------------------------------------------------------------- Comment By: Jeff Dean (jefdean) Date: 2006-10-30 03:09 Message: I've written an rspec_scaffold_resource generator and I'm just waiting to here back on a few questions about directory changes in trunk before submitting the patch - Jeff Dean ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 From noreply at rubyforge.org Thu Nov 9 08:40:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 08:40:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-5719 ] Improve Rails controller spec helpers Message-ID: <20061109134013.C4ACCA970038@rubyforge.org> Feature Requests item #5719, was opened at 2006-09-11 06:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5719&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Improve Rails controller spec helpers Initial Comment: RSpec is missing a number of features necessary for controller specs: We badly need an rspec equivalent of assert_redirected_to. There's response.redirect_url.should_be 'http://test.host/assets', but this is rather fragile, and liable to break depending on your routes setup. should_redirect_to {:action => 'index'} would be nice. Being able to use named routes would be extremely useful - eg "get accounts_url" or "delete account_url(@account)" (though it's perhaps worth noting that this doesn't even work in Rails' functional tests - you have to use integration tests if you want this to work) Some sort of routes testing is needed. Rails's functional tests use this : assert_recognizes({:controller => 'assets', :action => 'new'}, {:path => "/assets/new", :method => :get}) to verify that a given path maps to the appropriate controller & action. I'll add more as I find them. I'm willing to help with this if I can - I tried implementing my own should_redirect_to as a wrapper around assert_redirected_to, but started to run into problems with not knowing enough about how Rails sets up the test process... ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:40 Message: Fixed and moved to other RFEs ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-05 13:51 Message: Jonathon - 0.7 will have controller.should_redirect_to, which you can set in advance of an action. There is already an RFE for spec'ing routes: http://rubyforge.org/tracker/index.php?func=detail&aid=6471&group_id=797&atid=9464 And I've added one for supporting named routes: http://rubyforge.org/tracker/index.php?func=detail&aid=6501&group_id=797&atid=9464 In the future, please multiple features in separate RFEs to make it easier for us to track everything. Thank you! David ---------------------------------------------------------------------- Comment By: Jonathan del Strother (catfish) Date: 2006-09-12 12:00 Message: ahhh, I'v just found response.redirected_to.should_equal :action=>'index' which works fine. IMO should_redirect_to is much nicer-looking, but given I can't figure out how to do it without ugly hacks... ---------------------------------------------------------------------- Comment By: Jonathan del Strother (catfish) Date: 2006-09-11 07:49 Message: FWIW, here's a horrible hacked version of should_redirect_to: def should_redirect_to(redirect_target) #need to set up a results object for the assertion. It requires an add_assertion method... extras = Module.new {} extras.send('define_method', 'add_assertion', Proc.new{}) @_result = "unused" @_result.extend(extras) begin assert_redirected_to redirect_target rescue Test::Unit::AssertionFailedError => e spec_message = e.message.sub("response is not a redirection", "response should be a redirection") violated(spec_message) end end I'm assuming there's a better way of doing this, but suspect that it involves rewriting Rails' Test Process module, which makes my head hurt. I'll freely admit that I can't quite figure out the @_result object which seems to be required for calling assert methods, too... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5719&group_id=797 From noreply at rubyforge.org Thu Nov 9 08:34:37 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 08:34:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator Message-ID: <20061109133437.4C14552413F4@rubyforge.org> Feature Requests item #6098, was opened at 2006-10-11 06:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Make scaffold_resource generator Initial Comment: In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:34 Message: I tried this with RSpec's demo app (vendor/rspec_on_rails) - I created an account resource. The following code is failing: NoMethodError in 'The accountsController should map { :controller => 'accounts', :action => 'show', :id => 1 } to /accounts/1' undefined method `routing' for #<#:0x3b2d680> Where is this routing method defined? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-04 11:49 Message: My plugin at http://svn.flpr.org/public/plugins/rspec_resource_generator/ handles that. I removed the forked code, so the only template now is the controller_spec. Everything else is pulled from the standard Rails generators, and the rspec_model generator for the model spec. Anything else that should be done with that? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-04 04:28 Message: We should *not* fork/copy Rails code. Reuse all the existing templates, swap the test generation with spec generation (our own template). See the implementation of rspec_model and rspec_controller generators. ---------------------------------------------------------------------- Comment By: Jeff Dean (jefdean) Date: 2006-10-30 03:09 Message: I've written an rspec_scaffold_resource generator and I'm just waiting to here back on a few questions about directory changes in trunk before submitting the patch - Jeff Dean ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 From noreply at rubyforge.org Thu Nov 9 06:08:00 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 06:08:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6570 ] rSpec on Rails does not clean the test DB inbetween contexts Message-ID: <20061109110801.13A7BA970036@rubyforge.org> Bugs item #6570, was opened at 2006-11-08 12:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6570&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Timm Gebhart (onkeltimm) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rSpec on Rails does not clean the test DB inbetween contexts Initial Comment: Version: RSpec-0.7.0 (r1039) When I set up a context and load fixtures, those are not removed from the test DB before the next context is run, like this: # This runs fine context "Context with fixtures" do fixtures :tests specify "should have records" do Test.find(:all).should_not_be_empty end end # This fails context "Context w/o fixtures" do specify "should have no records" do Test.should_have(:no).records end end The Test DB should be clean upon entering a context. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 06:08 Message: I would take it up with Rails core. I'm sure there is a FAQ on it somewhere. ---------------------------------------------------------------------- Comment By: Timm Gebhart (onkeltimm) Date: 2006-11-09 05:42 Message: I might be misunderstanding, but this does not make sense to me at all. The reason there is a test database in the first place is that it gives you a reliable state at the beginning of each context/test/spec. To me, this implies that when i do not load fixtures at all, I get an empty DB (and this IS a boundary condition, and I have to test it). Also between different model's *_spec.rb files, the DB is never cleaned. How can I ensure I have a DB that is clean except for the structure in a contest/test/spec? I'd be happy to be enlightened, but this does seem like a design error to me. Wonder if I should bring this up in Rails core, what do you think? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 15:35 Message: This is by design in Rails. You would get the same behaviour if you used Test::Unit Just put fixtures :tests in the other context too. Or put it in the spec_helper.rb ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6570&group_id=797 From noreply at rubyforge.org Thu Nov 9 03:53:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 03:53:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6265 ] should_raise should accept an Exception object Message-ID: <20061109085313.2AD415240CC3@rubyforge.org> Feature Requests item #6265, was opened at 2006-10-21 22:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 Category: mock module Group: None >Status: Open Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: should_raise should accept an Exception object Initial Comment: So I can pass it an exception object with the message (or anything else) set on it. ---------------------------------------------------------------------- >Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-09 01:53 Message: Reopening this. I'll try to submit a patch for this soon. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-09 01:51 Message: OK, here's a failing spec which illustrates what I'm talking about. Basically, I want to provide my own pre-created exception to be thrown, with a specified error message. require 'rubygems' require 'spec' context "a mock" do specify "should allow a pre-created exception to be raised" do error_message = "msg" e = RuntimeError.new(error_message) errormock = mock("Mock") errormock.should_receive(:method).and_raise(e) errmsg = nil begin errormock.method rescue RuntimeError => e errmsg = e.message end errmsg.should_equal(error_message) end end ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-10-23 23:51 Message: Yes, I meant "and_raise", it was a typo. I will try the Proc#should_raise and see if that works. Thanks, Chad ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-22 05:42 Message: I'm a little confused. You categorised this RFE in the mock module. RSpec mocks don't have a sould_raise method, but an and_raise method (which allows you to pass in an exception) http://rspec.rubyforge.org/documentation/mocks.html http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/mocks/mock_spec.rb?revision=931&root=rspec Or perhaps you're talking about the Proc#should_raise method? It also allows you to pass an exception object: http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/expectations/should/should_raise_spec.rb?root=rspec&view=co http://rspec.rubyforge.org/documentation/expectations.html If this doesn't work for you, please submit a failing spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 From noreply at rubyforge.org Thu Nov 9 09:17:54 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 09:17:54 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator Message-ID: <20061109141754.655C55241443@rubyforge.org> Feature Requests item #6098, was opened at 2006-10-11 06:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Make scaffold_resource generator Initial Comment: In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 09:17 Message: I'm attaching a patch with some small improvements: should_eql and correct use of controller_class_name ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:41 Message: Looks like routing is defined in this "patch": http://rubyforge.org/tracker/index.php?func=detail&aid=6471&group_id=797&atid=3152 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:34 Message: I tried this with RSpec's demo app (vendor/rspec_on_rails) - I created an account resource. The following code is failing: NoMethodError in 'The accountsController should map { :controller => 'accounts', :action => 'show', :id => 1 } to /accounts/1' undefined method `routing' for #<#:0x3b2d680> Where is this routing method defined? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-04 11:49 Message: My plugin at http://svn.flpr.org/public/plugins/rspec_resource_generator/ handles that. I removed the forked code, so the only template now is the controller_spec. Everything else is pulled from the standard Rails generators, and the rspec_model generator for the model spec. Anything else that should be done with that? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-04 04:28 Message: We should *not* fork/copy Rails code. Reuse all the existing templates, swap the test generation with spec generation (our own template). See the implementation of rspec_model and rspec_controller generators. ---------------------------------------------------------------------- Comment By: Jeff Dean (jefdean) Date: 2006-10-30 03:09 Message: I've written an rspec_scaffold_resource generator and I'm just waiting to here back on a few questions about directory changes in trunk before submitting the patch - Jeff Dean ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 From noreply at rubyforge.org Thu Nov 9 13:34:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 13:34:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6575 ] Parse error in aliasing the partial mock original method Message-ID: <20061109183405.665D05241BF0@rubyforge.org> Bugs item #6575, was opened at 2006-11-08 14:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 Category: mock module Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: Parse error in aliasing the partial mock original method Initial Comment: Here is code that caused the error in Rspec 0.7.0. It worked in version 0.6.*: @rake_application = @builder.rake_application = mock("rake_application") ... @rake_application.should_receive(:last_comment=).with("Builds the #{extension} extension") ---- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:116:in `metaclass_eval': (eval):2:in `metaclass_eval': compile error (SyntaxError) (eval):2: parse error, unexpected tIDENTIFIER, expecting $ alias_method :original_exists?_before_proxy, :exists? ^ from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:56:in `define_expected_method' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:45:in `__add' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:26:in `add_message_expectation' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_methods.rb:5:in `should_receive' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:127:in `__instance_exec0' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `instance_exec' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/specification.rb:28:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:45:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:4 ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2006-11-09 10:34 Message: I submitted this because the build is currently broken. I did not want to make a branch for such a small change. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-09 10:32 Message: I'm going to attatch a patch that puts the original method object into a hash rather than relying on method aliasing. This will make this code less fragile. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 15:48 Message: Fixed in r1059 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-08 15:23 Message: Here is a quick fix I put into my spec_helper.rb module Spec module Mocks class MockHandler def __pre_proxied_method_name method_name "original_#{method_name.to_s.delete('!').delete('=').delete('?').delete('[').delete('\]')}_before_proxy" end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 From noreply at rubyforge.org Thu Nov 9 13:42:21 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 13:42:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6575 ] Parse error in aliasing the partial mock original method Message-ID: <20061109184221.F1FC3A970016@rubyforge.org> Bugs item #6575, was opened at 2006-11-08 14:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 Category: mock module Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: Parse error in aliasing the partial mock original method Initial Comment: Here is code that caused the error in Rspec 0.7.0. It worked in version 0.6.*: @rake_application = @builder.rake_application = mock("rake_application") ... @rake_application.should_receive(:last_comment=).with("Builds the #{extension} extension") ---- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:116:in `metaclass_eval': (eval):2:in `metaclass_eval': compile error (SyntaxError) (eval):2: parse error, unexpected tIDENTIFIER, expecting $ alias_method :original_exists?_before_proxy, :exists? ^ from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:56:in `define_expected_method' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:45:in `__add' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:26:in `add_message_expectation' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_methods.rb:5:in `should_receive' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:127:in `__instance_exec0' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `instance_exec' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/specification.rb:28:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:45:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:4 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-09 10:34 Message: I submitted this because the build is currently broken. I did not want to make a branch for such a small change. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-09 10:32 Message: I'm going to attatch a patch that puts the original method object into a hash rather than relying on method aliasing. This will make this code less fragile. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 15:48 Message: Fixed in r1059 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-08 15:23 Message: Here is a quick fix I put into my spec_helper.rb module Spec module Mocks class MockHandler def __pre_proxied_method_name method_name "original_#{method_name.to_s.delete('!').delete('=').delete('?').delete('[').delete('\]')}_before_proxy" end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 From noreply at rubyforge.org Thu Nov 9 13:32:46 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 13:32:46 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6575 ] Parse error in aliasing the partial mock original method Message-ID: <20061109183246.658105241BEC@rubyforge.org> Bugs item #6575, was opened at 2006-11-08 14:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 Category: mock module Group: None >Status: Open Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) >Assigned to: Brian Takita (btakita) Summary: Parse error in aliasing the partial mock original method Initial Comment: Here is code that caused the error in Rspec 0.7.0. It worked in version 0.6.*: @rake_application = @builder.rake_application = mock("rake_application") ... @rake_application.should_receive(:last_comment=).with("Builds the #{extension} extension") ---- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:116:in `metaclass_eval': (eval):2:in `metaclass_eval': compile error (SyntaxError) (eval):2: parse error, unexpected tIDENTIFIER, expecting $ alias_method :original_exists?_before_proxy, :exists? ^ from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:56:in `define_expected_method' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:45:in `__add' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:26:in `add_message_expectation' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_methods.rb:5:in `should_receive' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:127:in `__instance_exec0' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `instance_exec' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/specification.rb:28:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:45:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:4 ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2006-11-09 10:32 Message: I'm going to attatch a patch that puts the original method object into a hash rather than relying on method aliasing. This will make this code less fragile. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 15:48 Message: Fixed in r1059 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-08 15:23 Message: Here is a quick fix I put into my spec_helper.rb module Spec module Mocks class MockHandler def __pre_proxied_method_name method_name "original_#{method_name.to_s.delete('!').delete('=').delete('?').delete('[').delete('\]')}_before_proxy" end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 From noreply at rubyforge.org Thu Nov 9 14:18:44 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 14:18:44 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6575 ] Parse error in aliasing the partial mock original method Message-ID: <20061109191845.B32195241C04@rubyforge.org> Bugs item #6575, was opened at 2006-11-08 17:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 Category: mock module Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: Parse error in aliasing the partial mock original method Initial Comment: Here is code that caused the error in Rspec 0.7.0. It worked in version 0.6.*: @rake_application = @builder.rake_application = mock("rake_application") ... @rake_application.should_receive(:last_comment=).with("Builds the #{extension} extension") ---- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:116:in `metaclass_eval': (eval):2:in `metaclass_eval': compile error (SyntaxError) (eval):2: parse error, unexpected tIDENTIFIER, expecting $ alias_method :original_exists?_before_proxy, :exists? ^ from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:56:in `define_expected_method' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:45:in `__add' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:26:in `add_message_expectation' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_methods.rb:5:in `should_receive' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:127:in `__instance_exec0' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `instance_exec' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/specification.rb:28:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:45:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:4 ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 14:18 Message: The build is currently broken only against Ruby 1.8.5. It should be fine for 1.8.4. Go ahead and commit it if it works on 1.8.4. Making RSpec (spec/rails) work on 1.8.5 is not a priority as long as Rails doesn't support 1.8.5. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-09 13:34 Message: I submitted this because the build is currently broken. I did not want to make a branch for such a small change. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-09 13:32 Message: I'm going to attatch a patch that puts the original method object into a hash rather than relying on method aliasing. This will make this code less fragile. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 18:48 Message: Fixed in r1059 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-08 18:23 Message: Here is a quick fix I put into my spec_helper.rb module Spec module Mocks class MockHandler def __pre_proxied_method_name method_name "original_#{method_name.to_s.delete('!').delete('=').delete('?').delete('[').delete('\]')}_before_proxy" end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 From noreply at rubyforge.org Thu Nov 9 13:33:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 13:33:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6575 ] Parse error in aliasing the partial mock original method Message-ID: <20061109183312.417BC5241BF0@rubyforge.org> Bugs item #6575, was opened at 2006-11-08 14:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 Category: mock module Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: Parse error in aliasing the partial mock original method Initial Comment: Here is code that caused the error in Rspec 0.7.0. It worked in version 0.6.*: @rake_application = @builder.rake_application = mock("rake_application") ... @rake_application.should_receive(:last_comment=).with("Builds the #{extension} extension") ---- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:116:in `metaclass_eval': (eval):2:in `metaclass_eval': compile error (SyntaxError) (eval):2: parse error, unexpected tIDENTIFIER, expecting $ alias_method :original_exists?_before_proxy, :exists? ^ from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:56:in `define_expected_method' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:45:in `__add' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:26:in `add_message_expectation' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_methods.rb:5:in `should_receive' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:127:in `__instance_exec0' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `instance_exec' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/specification.rb:28:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:45:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:4 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-09 10:32 Message: I'm going to attatch a patch that puts the original method object into a hash rather than relying on method aliasing. This will make this code less fragile. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 15:48 Message: Fixed in r1059 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-08 15:23 Message: Here is a quick fix I put into my spec_helper.rb module Spec module Mocks class MockHandler def __pre_proxied_method_name method_name "original_#{method_name.to_s.delete('!').delete('=').delete('?').delete('[').delete('\]')}_before_proxy" end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 From noreply at rubyforge.org Thu Nov 9 13:41:44 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 13:41:44 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6575 ] Parse error in aliasing the partial mock original method Message-ID: <20061109184144.E35C55241BF0@rubyforge.org> Bugs item #6575, was opened at 2006-11-08 14:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 Category: mock module Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: Parse error in aliasing the partial mock original method Initial Comment: Here is code that caused the error in Rspec 0.7.0. It worked in version 0.6.*: @rake_application = @builder.rake_application = mock("rake_application") ... @rake_application.should_receive(:last_comment=).with("Builds the #{extension} extension") ---- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:116:in `metaclass_eval': (eval):2:in `metaclass_eval': compile error (SyntaxError) (eval):2: parse error, unexpected tIDENTIFIER, expecting $ alias_method :original_exists?_before_proxy, :exists? ^ from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:56:in `define_expected_method' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:45:in `__add' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:26:in `add_message_expectation' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_methods.rb:5:in `should_receive' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:127:in `__instance_exec0' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `instance_exec' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/specification.rb:28:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:45:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:4 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-09 10:34 Message: I submitted this because the build is currently broken. I did not want to make a branch for such a small change. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-09 10:32 Message: I'm going to attatch a patch that puts the original method object into a hash rather than relying on method aliasing. This will make this code less fragile. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 15:48 Message: Fixed in r1059 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-08 15:23 Message: Here is a quick fix I put into my spec_helper.rb module Spec module Mocks class MockHandler def __pre_proxied_method_name method_name "original_#{method_name.to_s.delete('!').delete('=').delete('?').delete('[').delete('\]')}_before_proxy" end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 From noreply at rubyforge.org Thu Nov 9 14:44:31 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 14:44:31 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6575 ] Parse error in aliasing the partial mock original method Message-ID: <20061109194433.179485241C18@rubyforge.org> Bugs item #6575, was opened at 2006-11-08 22:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 Category: mock module Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: Parse error in aliasing the partial mock original method Initial Comment: Here is code that caused the error in Rspec 0.7.0. It worked in version 0.6.*: @rake_application = @builder.rake_application = mock("rake_application") ... @rake_application.should_receive(:last_comment=).with("Builds the #{extension} extension") ---- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:116:in `metaclass_eval': (eval):2:in `metaclass_eval': compile error (SyntaxError) (eval):2: parse error, unexpected tIDENTIFIER, expecting $ alias_method :original_exists?_before_proxy, :exists? ^ from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:56:in `define_expected_method' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:45:in `__add' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_handler.rb:26:in `add_message_expectation' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/mocks/mock_methods.rb:5:in `should_receive' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:127:in `__instance_exec0' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `send' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/object.rb:15:in `instance_exec' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/specification.rb:28:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:45:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:44:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `each' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from /home/btakita/workspace/fjson/spec/mkmf_rake_builder_spec.rb:4 ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-09 19:44 Message: Fixed in trunk (rev 1072) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 19:18 Message: The build is currently broken only against Ruby 1.8.5. It should be fine for 1.8.4. Go ahead and commit it if it works on 1.8.4. Making RSpec (spec/rails) work on 1.8.5 is not a priority as long as Rails doesn't support 1.8.5. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-09 18:34 Message: I submitted this because the build is currently broken. I did not want to make a branch for such a small change. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-09 18:32 Message: I'm going to attatch a patch that puts the original method object into a hash rather than relying on method aliasing. This will make this code less fragile. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 23:48 Message: Fixed in r1059 ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-11-08 23:23 Message: Here is a quick fix I put into my spec_helper.rb module Spec module Mocks class MockHandler def __pre_proxied_method_name method_name "original_#{method_name.to_s.delete('!').delete('=').delete('?').delete('[').delete('\]')}_before_proxy" end end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6575&group_id=797 From noreply at rubyforge.org Thu Nov 9 14:44:55 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 14:44:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6277 ] debris left by stubbing (trunk) [submitted by dastels] Message-ID: <20061109194456.07C955241C10@rubyforge.org> Bugs item #6277, was opened at 2006-10-22 22:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6277&group_id=797 >Category: mock module Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Nobody (None) >Assigned to: Brian Takita (btakita) Summary: debris left by stubbing (trunk) [submitted by dastels] Initial Comment: stubs leave some sort of residue in one file/context (#1) I have: context "Setting the name" do fixtures :users, :roles, :rights controller_name 'admin/dj' setup do roles(:admin).rights << rights(:admin) users(:rod).roles << roles(:admin) @session[:user] = users('rod').id @dj = Dj.new(:id => 1, :name => 'Joe') @dj.stub!(:update_attribute) @dj.stub!(:name).and_return('Dave') Dj.stub!(:find).and_return(@dj) Dj.should_receive(:find).with(:all).and_return([[@dj]]) end specify "should update the name" do @dj.should_receive(:update_attribute).with(:name, 'Dave') post 'set_dj_name', :id => 1, :value => 'Dave' end specify "should render the list" do post 'set_dj_name', :id => 1, :value => 'Dave' response.should_have_rjs :replace_html, 'itemList', /Dave/ end specify "should render the dj data" do post 'set_dj_name', :id => 1, :value => 'Dave' response.should_have_rjs :replace_html, 'itemData', /Dave/ end end in another (#2): context "Asking for a list" do fixtures :djs, :users, :roles, :rights controller_name 'admin/dj' setup do roles(:admin).rights << rights(:admin) users(:rod).roles << roles(:admin) @session[:user] = users('rod').id get 'list' end specify "should get some djs" do assigns('dj_list').should_not_be_nil end specify "should get all djs" do assigns('dj_list').size.should_equal 4 end end if #1 runs first, both specs in #2 fail (the invoked action calls Dj.find(:all). Failure is: "undefined method `find' for Dj:Class" if #2 is run alone, or first, everythign passes. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-09 19:44 Message: Fixed in trunk (rev 1072) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 11:07 Message: Is this still a problem in 0.7? If so, can you provide some simple spec and code to reproduce? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6277&group_id=797 From daniel at dr-siemssen.de Thu Nov 9 17:29:55 2006 From: daniel at dr-siemssen.de (Daniel Siemssen) Date: Thu, 09 Nov 2006 23:29:55 +0100 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: References: <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> <84BAE719-E829-426B-9395-F40F4B0B8A66@gmail.com> <8d961d900611082033l51454023h685a553cb983499@mail.gmail.com> <8d961d900611082046v7c66a365h3c811ecab106859c@mail.gmail.com> <90DC39CC-6144-4BD3-9F55-C309A6D9642A@agileevolved.com> <8d961d900611090432y526194b8lc2064a73e7b6f129@mail.gmail.com> Message-ID: <4553ABE3.8080400@dr-siemssen.de> On 09.11.2006 14:49, Luke Redpath wrote: > On 9 Nov 2006, at 12:32, aslak hellesoy wrote: > >> >> Oh definitely. The blue on red is awful. And the general fonts/layout >> (in RSpec core) can be improved too. Feel free to improve >> html_formatted.html (and the HtmlFormatter class) > > I'll have a bash! > >> >> No ETA AFAIK, but I see no reason to delay it. > > Maybe its best to wait a week or so in case any other major bugs get > found? > >> Really? Got some HTML? > > Nope (I've reverted back to 0.7 for now) but the problem appears to be > elsewhere as I can reproduce on the command line with the specdoc format: > > --- > spec --format specdoc user_spec.rb > --- > outputs: > --- > Spec::Rails::ContextFactory > - should be authenticatable > - should be valid with valid attributes > - should be invalid without an email > - should be invalid without a password > - should be invalid if password is less than 5 characters in length > - should be invalid without a unique email > - should be invalid without a matching password confirmation > > Spec::Rails::ContextFactory > - should not be enabled > - should not be activated > - should have no credit cards > - should have no sales > - should have no purchases > > Spec::Rails::ContextFactory > - should be authenticatable by its email address > - should not be activated > - should not be enabled > - should have a generated activation key > - can be activated with the correct activation key > - should be enabled after successful activation > > Spec::Rails::ContextFactory > - should return nil if given an invalid activation key > > Spec::Rails::ContextFactory > - should have a new randomly generated password > - should not be able to login with old password after save > - should be able to log in with new password after save > > I think the bug is in the Rails plugin as I cannot reproduce this with > specs for non-Rails apps - they work fine. > I've submitted a patch to fix that: https://rubyforge.org/tracker/index.php?func=detail&aid=6587&group_id=797&atid=3151 Daniel > Cheers > Luke > >> >> Aslak >> >>> Cheers >>> Luke >>> >>> On 9 Nov 2006, at 04:46, aslak hellesoy wrote: >>> >>> On 11/9/06, aslak hellesoy >> > wrote: >>> Attached is a (big) patch of RSpec.tmbundle that leverages RSpec >>> core's HmlFormatter. >>> The code is a lot simpler now. >>> >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >>> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > ------------------------------------------------------------------------ > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From george at benevolentcode.com Thu Nov 9 22:05:10 2006 From: george at benevolentcode.com (George Anderson) Date: Thu, 9 Nov 2006 22:05:10 -0500 Subject: [rspec-devel] Failure message for "string".should_equal "string" Message-ID: <782d66f30611091905r1a70cd86icdfc6157e581b653@mail.gmail.com> This may be overkill, but bear with me. should_equal tests for object identity. Typically when a should_equal expectation fails, the failure message is straightforward. For example, "1 should equal 2" is evident. However, in the case of strings and arrays, it's not always so clear. Witness: "string".should_equal "string" => FAILED: "string" should equal "string" [].should_equal [] => FAILED: [] should equal [] It may be pandering to the noobs in the crowd (I consider myself well within their ranks), but it seems the failure message would be more clear if it included some distinguishing information, such as object_ids. Something like: "string".should_equal "string" => FAILED: "string" should equal "string" [].should_equal [] => FAILED: [] should equal [] Granted, it's not elegant/pretty/terse, but the issue at hand is more obvious. Adding object_ids may do little more than help the less experienced among us (ahem) learn more quickly the distinction between should_equal, should_eql, and should ==, hence my initial "overkill" comment. Having gone through the exercise of hacking (truly) together support for this, I've now clearly gotten this distinction. Thoughts? /george -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061109/a507b244/attachment.html From lists-rspec at shopwatch.org Thu Nov 9 22:15:17 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Thu, 09 Nov 2006 22:15:17 -0500 Subject: [rspec-devel] Mocking in the past tense Message-ID: <4553EEC5.7090403@shopwatch.org> I'm in the process of converting my controller specs into TRUE controller specs (not just semi-integration specs), and I'm realizing that, for the same reason we have controller.should_have_rendered, we need mocking in the past tense, or - more likely - a better setup solution. The common case for a controller spec has context "/controller/something" setup do get 'something' end and then a bunch of specs that ensure the 'something' action does what it's supposed to. Well, if you spec this by mocking, instead of specifying state, there's really no way to put that "get" into setup. If you did, then all your mocks would have to go into setup too - and that means your entire spec is in setup. Right now, I'm solving this by putting the get into a subroutine and calling it repeatedly in each spec. That doesn't feel DRY. On the other hand, I can't think of an improvement that doesn't have at least a "yield" in the middle of a spec, and I'm not sure that's such an improvement. Any thoughts? Jay From dchelimsky at gmail.com Thu Nov 9 23:11:25 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 9 Nov 2006 22:11:25 -0600 Subject: [rspec-devel] Mocking in the past tense In-Reply-To: <4553EEC5.7090403@shopwatch.org> References: <4553EEC5.7090403@shopwatch.org> Message-ID: <57c63afe0611092011s54ad4148t51c597f188b2c0d3@mail.gmail.com> On 11/9/06, Jay Levitt wrote: > I'm in the process of converting my controller specs into TRUE > controller specs (not just semi-integration specs), and I'm realizing > that, for the same reason we have controller.should_have_rendered. Actually, the reason we have controller.should_have_rendered is to make the 0.6 > 0.7 transition just a little easier. I'd just as soon get rid of it! :) > , we need mocking in the past tense, or - more likely - a better setup solution. > > The common case for a controller spec has > > context "/controller/something" > setup do > get 'something' > end > > and then a bunch of specs that ensure the 'something' action does what > it's supposed to. > > Well, if you spec this by mocking, instead of specifying state, there's > really no way to put that "get" into setup. If you did, then all your > mocks would have to go into setup too - and that means your entire spec > is in setup. > > Right now, I'm solving this by putting the get into a subroutine and > calling it repeatedly in each spec. That doesn't feel DRY. While I agree that DRY is important in the subject code, in my opinion DRY is overrated when it comes to specs. The problem w/ DRY is not that you have to change things twice. The real problem is when you don't KNOW the other place you have to change it because it's off in some other file somewhere. In a case like this, I like to just add a method to execute the action and call that: context "..." do def do_get get 'some_action' end specify "one thing" do do_get verify_something end specify "another thing" do expect_something do_get end end For me, that makes the whole thing very clear and it gets closer to DRY w/o being nuts about doing so. > On the > other hand, I can't think of an improvement that doesn't have at least a > "yield" in the middle of a spec, and I'm not sure that's such an > improvement. > > Any thoughts? The idea of past-tense mocking has come up before. The problem is that it only provides value in a very limited subset of potential uses. With instances of Spec::Mocks::Mock, you could do something like this: setup do @mock = mock("whatever", :record_messages => true) @subject = Subject.new(@mock) end specify "..." do @subject.do_something @mock.should_have_received(:some_message).with(:some, :values) end But this quickly breaks down when :some_message has to return something. And it gets more strange when dealing w/ intercepting calls to pre-existing objects and classes. So, for me, I'd rather absorb the subtle dampness of the do_get method and keep the specs clear. Thoughts? > > Jay > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Thu Nov 9 21:08:21 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 21:08:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6591 ] rails_dpec like functionality in RSpec.tmbundle Message-ID: <20061110020821.C6A0A5241C62@rubyforge.org> Feature Requests item #6591, was opened at 2006-11-09 20:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6591&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rails_dpec like functionality in RSpec.tmbundle Initial Comment: For Rails development, it would be great to be able to run specs via DRb, to connect to rails_spec_server. I think the rails_spec script ought to be made a first-class RSpec core bin script: drbspec. Then it could be reused from commandline, editors/ides and other clients. Also see: http://www.artima.com/forums/flat.jsp?forum=123&thread=144337 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6591&group_id=797 From noreply at rubyforge.org Thu Nov 9 21:28:55 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 21:28:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6595 ] RcovHtmlFormatter Message-ID: <20061110022856.B5A0BA970016@rubyforge.org> Feature Requests item #6595, was opened at 2006-11-09 21:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6595&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RcovHtmlFormatter Initial Comment: It would work in a similar way to TextMateFormatter, except it would link to an RCov HTML report (at the right line). This would probably rely on an environment variable to get the relative path from the HTML to the RCov report. Useful for bigger projects in a CI environment. Some of the linking code in TextMateFormatter should be factored back to HtmlFormatter. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6595&group_id=797 From noreply at rubyforge.org Thu Nov 9 19:04:03 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 19:04:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6589 ] New -l --line option Message-ID: <20061110000404.1CA9CA970002@rubyforge.org> Feature Requests item #6589, was opened at 2006-11-09 19:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6589&group_id=797 Category: runner / command line Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: New -l --line option Initial Comment: Having such an option would make it much easier to write external (ide/editor) extensions for RSpec. See the thread below for details (remember to add docs for this). http://rubyforge.org/pipermail/rspec-users/2006-November/000176.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6589&group_id=797 From noreply at rubyforge.org Thu Nov 9 21:10:21 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 21:10:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6591 ] rails_dpec like functionality in RSpec.tmbundle Message-ID: <20061110021021.64B825241C63@rubyforge.org> Feature Requests item #6591, was opened at 2006-11-09 20:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6591&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rails_dpec like functionality in RSpec.tmbundle Initial Comment: For Rails development, it would be great to be able to run specs via DRb, to connect to rails_spec_server. I think the rails_spec script ought to be made a first-class RSpec core bin script: drbspec. Then it could be reused from commandline, editors/ides and other clients. Also see: http://www.artima.com/forums/flat.jsp?forum=123&thread=144337 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 21:09 Message: Let's not forget to update the spec/rails doco when we do this ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6591&group_id=797 From noreply at rubyforge.org Thu Nov 9 17:27:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 17:27:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6587 ] Rspec on Rails displays "Spec::Rails::ContextFactory" as context name Message-ID: <20061109222750.41721A970039@rubyforge.org> Patches item #6587, was opened at 2006-11-09 23:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6587&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel Siemssen (dsiem) Assigned to: Nobody (None) Summary: Rspec on Rails displays "Spec::Rails::ContextFactory" as context name Initial Comment: If you put your RoR specs in a different directory than views/, helpers/, models/ or controllers/ and don't define the :context_type manually, then Rspec on Rails won't display the context name but "Spec::Rails::ContextFactory" instead. This patch should resolve this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6587&group_id=797 From noreply at rubyforge.org Thu Nov 9 19:19:06 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 19:19:06 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6587 ] Rspec on Rails displays "Spec::Rails::ContextFactory" as context name Message-ID: <20061110001906.C4F895241C47@rubyforge.org> Patches item #6587, was opened at 2006-11-09 17:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6587&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Daniel Siemssen (dsiem) >Assigned to: Aslak Helles?y (aslak_hellesoy) >Summary: Rspec on Rails displays "Spec::Rails::ContextFactory" as context name Initial Comment: If you put your RoR specs in a different directory than views/, helpers/, models/ or controllers/ and don't define the :context_type manually, then Rspec on Rails won't display the context name but "Spec::Rails::ContextFactory" instead. This patch should resolve this. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 19:19 Message: Applied in r1075 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6587&group_id=797 From noreply at rubyforge.org Thu Nov 9 21:09:42 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 21:09:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6591 ] rails_dpec like functionality in RSpec.tmbundle Message-ID: <20061110020942.A21EC5241C62@rubyforge.org> Feature Requests item #6591, was opened at 2006-11-09 20:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6591&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rails_dpec like functionality in RSpec.tmbundle Initial Comment: For Rails development, it would be great to be able to run specs via DRb, to connect to rails_spec_server. I think the rails_spec script ought to be made a first-class RSpec core bin script: drbspec. Then it could be reused from commandline, editors/ides and other clients. Also see: http://www.artima.com/forums/flat.jsp?forum=123&thread=144337 ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 21:09 Message: Let's not forget to update the spec/rails doco when we do this ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6591&group_id=797 From noreply at rubyforge.org Thu Nov 9 21:28:55 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 21:28:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6594 ] trunk doesn't always rollback new records after controller specs Message-ID: <20061110022858.12BA9A97001C@rubyforge.org> Bugs item #6594, was opened at 2006-11-09 21:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6594&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: trunk doesn't always rollback new records after controller specs Initial Comment: Given the rails app below: spec spec/models/person_spec.rb works. spec spec/controllers/test_controller_spec.rb spec/models/person_spec.rb fails with "ActiveRecord::RecordInvalid in 'A Person should create reggie' Validation failed: Name has already been taken" because the record already exists by the time it gets to person_spec. # testapp/db/migrate/001_create_people.rb class CreatePeople < ActiveRecord::Migration def self.up create_table "people" do |t| t.column "name", :string end end def self.down end end # testapp/models/person.rb class Person < ActiveRecord::Base validates_uniqueness_of :name end # testapp/controllers/test_controller.rb class TestController < ActionController::Base def new p = Person.new p.name = "reggie" p.save! render :text => "created reggie" end end # spec/models/person_spec.rb require File.dirname(__FILE__) + '/../spec_helper' context "A Person" do specify "should create reggie" do p = Person.new p.name = "reggie" p.save! end end # spec/controllers/test_controller.rb require File.dirname(__FILE__) + '/../spec_helper' context "the test app" do controller_name :test specify "should create reggie" do get 'new' response.body.should_match /created/ end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6594&group_id=797 From noreply at rubyforge.org Thu Nov 9 20:53:10 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 20:53:10 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6591 ] rails_dpec like functionality in RSpec.tmbundle Message-ID: <20061110015310.EEEA45241C4E@rubyforge.org> Feature Requests item #6591, was opened at 2006-11-09 20:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6591&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: rails_dpec like functionality in RSpec.tmbundle Initial Comment: For Rails development, it would be great to be able to run specs via DRb, to connect to rails_spec_server. I think the rails_spec script ought to be made a first-class RSpec core bin script: drbspec. Then it could be reused from commandline, editors/ides and other clients. Also see: http://www.artima.com/forums/flat.jsp?forum=123&thread=144337 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6591&group_id=797 From noreply at rubyforge.org Thu Nov 9 21:19:48 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 21:19:48 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6593 ] Add moving progress bar to HtmlFormatter using Javascript Message-ID: <20061110021949.0CCA75241C6A@rubyforge.org> Feature Requests item #6593, was opened at 2006-11-09 21:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6593&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Add moving progress bar to HtmlFormatter using Javascript Initial Comment: TDDMate (http://iamrice.org/articles/2006/02/25/edge-rails-and-tddmate) has a nifty feature to make a progress bar progress. When this is loaded slowly (by the speed of test test execution) in the browser, the HTML and Javascript will come into the browser little by little. Very useful for RSpec.tmbundle. It can be simulated by setting up a tiny WEBRick running specs (for manual testing) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6593&group_id=797 From noreply at rubyforge.org Thu Nov 9 19:37:08 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 9 Nov 2006 19:37:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6471 ] Easy way to spec routes Message-ID: <20061110003709.28250A97003D@rubyforge.org> Patches item #6471, was opened at 2006-11-03 13:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6471&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Pat Maddox (pergesu) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Easy way to spec routes Initial Comment: I'd like to specify that my routes are generating correctly, as shown below: context "The EventsController" do controller_name :events specify "should be a EventsController" do controller.should_be_an_instance_of EventsController end specify "should map { :controller => 'events', :action => 'index' } to /events" do routing(:controller => "events", :action => "index").should_equal "/events" end specify "should map { :controller => 'events', :action => 'show', :id => 1 } to /events/1" do routing(:controller => "events", :action => "show", :id => 1).should_equal "/events/1" end specify "should map { :controller => 'events', :action => 'edit', :id => 1 } to /events/1;edit" do routing(:controller => "events", :action => "edit", :id => 1).should_equal "/events/1;edit" end specify "should map { :controller => 'events', :action => 'new' } to /events/new" do routing(:controller => "events", :action => "new").should_equal "/events/new" end end I made it work by adding the following method to Spec::Runner::ContextEval::InstanceMethods def routing(options) # Load routes.rb if it hasn't been loaded ActionController::Routing::Routes.reload if ActionController::Routing::Routes.empty? ActionController::Routing::Routes.generate(options) end Sorry I don't have any specs for it..the rspec_rails 0.6.4 plugin doesn't have any specs to add to. Not sure how robust this will be (it only uses a tiny part of the code from Rails' assert_routing), but so far it's worked for all of my basic routes. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 19:37 Message: Applied in r1076 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 09:11 Message: I'm moving this to a patch. This patch must be applied in order to get rspec_resource to work (http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797) I'm not applying it yet since there are no specs, and it doesn't seem to work with Rails 1.1.6 (the latest release as of this writing) ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-04 23:20 Message: re: testing rails. It's basically the same as when you have validations set up in your model. You test to make sure those are working, right? It's certainly behavior, even if Rails takes care of the hard part. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-11-04 21:06 Message: There's also the opposite operation of recognising a url using the routing patterns... also produces matched params hash, plus an "extras" hash. Like specify "should recognise /events/1;edit as { :controller => 'events', :action => 'edit', :id => 1 }" do route_recognise("/events/1;edit").should_equal(:controller => "events", :action => "edit", :id => 1) end This kind of expectation might be mooted by integration speccing. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-11-04 21:01 Message: I had a look at this too a while back. I think there needs to be a second argument to #routing through which you can send the "extra" parameters. I was assuming that these are arbitrary parameters which don't fit into the rest of the route pattern, and are generated out as the query of the url. Does that sound right? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-04 16:38 Message: This is very useful for verifying custom routes (config/routes.rb) , which is rather common in Rails apps. It's not testing rails, it's testing *your* routes. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-04 15:02 Message: This seems like you're testing rails as opposed to specifying the behaviour of your code. Am I missing something? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6471&group_id=797 From dchelimsky at gmail.com Fri Nov 10 05:58:37 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 10 Nov 2006 04:58:37 -0600 Subject: [rspec-devel] most active Message-ID: <57c63afe0611100258u9346257rff85614f69abd123@mail.gmail.com> Here's something I never expected to see! With all the feedback on 0.7, we achieved Most Active status on rubyforge! Thanks to all for the invaluable feedback. And keep it coming! Cheers, David -------------- next part -------------- A non-text attachment was scrubbed... Name: most_active.jpg Type: image/jpeg Size: 6155 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061110/82dde472/attachment-0001.jpg From aslak.hellesoy at gmail.com Fri Nov 10 06:50:51 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 10 Nov 2006 12:50:51 +0100 Subject: [rspec-devel] most active In-Reply-To: <57c63afe0611100258u9346257rff85614f69abd123@mail.gmail.com> References: <57c63afe0611100258u9346257rff85614f69abd123@mail.gmail.com> Message-ID: <8d961d900611100350u430d4184nef6c046d442432cd@mail.gmail.com> On 11/10/06, David Chelimsky wrote: > Here's something I never expected to see! With all the feedback on > 0.7, we achieved Most Active status on rubyforge! > > Thanks to all for the invaluable feedback. And keep it coming! > Wow that's almost scary!! Aslak > Cheers, > David > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From dchelimsky at gmail.com Fri Nov 10 09:36:28 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 10 Nov 2006 08:36:28 -0600 Subject: [rspec-devel] [ANN] RSpec-0.7.1 Message-ID: <57c63afe0611100636n70e84938i44c92f3f4b2e87eb@mail.gmail.com> RSpec-0.7.1 is now available. It comprises some bug fixes and a couple of new features. This is recommended for anybody who has already upgraded to 0.7.0. If you are running 0.6.x (or earlier), read this first: http://rspec.rubyforge.org/upgrade.html Install gem: gem install rspec Download: http://rubyforge.org/frs/?group_id=797 Release Notes: http://rubyforge.org/frs/shownotes.php?release_id=7846 RSpec site: http://rspec.rubyforge.org/ Happy designing! David From noreply at rubyforge.org Fri Nov 10 06:57:42 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 06:57:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6594 ] trunk doesn't always rollback new records after controller specs Message-ID: <20061110115743.188BA5241422@rubyforge.org> Bugs item #6594, was opened at 2006-11-09 21:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6594&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Jay Levitt (jaylev) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: trunk doesn't always rollback new records after controller specs Initial Comment: Given the rails app below: spec spec/models/person_spec.rb works. spec spec/controllers/test_controller_spec.rb spec/models/person_spec.rb fails with "ActiveRecord::RecordInvalid in 'A Person should create reggie' Validation failed: Name has already been taken" because the record already exists by the time it gets to person_spec. # testapp/db/migrate/001_create_people.rb class CreatePeople < ActiveRecord::Migration def self.up create_table "people" do |t| t.column "name", :string end end def self.down end end # testapp/models/person.rb class Person < ActiveRecord::Base validates_uniqueness_of :name end # testapp/controllers/test_controller.rb class TestController < ActionController::Base def new p = Person.new p.name = "reggie" p.save! render :text => "created reggie" end end # spec/models/person_spec.rb require File.dirname(__FILE__) + '/../spec_helper' context "A Person" do specify "should create reggie" do p = Person.new p.name = "reggie" p.save! end end # spec/controllers/test_controller.rb require File.dirname(__FILE__) + '/../spec_helper' context "the test app" do controller_name :test specify "should create reggie" do get 'new' response.body.should_match /created/ end end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-10 06:57 Message: This is a Rails feature. Rollback only happens for explicit fixtures. You'd get the same behaviour with Test::Unit. In your example you need: fixtures :people Either in your spec_helper or in all the specs creating Person records. Please reopen this if that doesn't fix your problem. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6594&group_id=797 From noreply at rubyforge.org Fri Nov 10 11:04:08 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 11:04:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6608 ] RSpec 0.7.1 with ZenTest 3.4.2 raise TypeError on TestSession Message-ID: <20061110160409.077D5A970009@rubyforge.org> Bugs item #6608, was opened at 2006-11-11 00:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6608&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) Assigned to: Nobody (None) Summary: RSpec 0.7.1 with ZenTest 3.4.2 raise TypeError on TestSession Initial Comment: ZenTest 3.4.2 defines TestSession is a Hash in their test_help.rb, althought Rails doesn't so neither pre-1.2 nor edge. I don't know why they've done that in 3.4.2 as I couldn't find ZenTest src repository... $ pwd /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails $ script/generate rspec exists spec identical spec/spec_helper.rb identical script/rails_spec identical script/rails_spec_server $ rake -q spec:app (in /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails) /Users/shintaro/gem.repos/gems/ZenTest-3.4.2/test/test_help.rb:5: superclass mismatch for class TestSession (TypeError) from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /Users/shintaro/gem.repos/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /Users/shintaro/gem.repos/gems/ZenTest-3.4.2/lib/test/rails.rb:2 from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `gem_original_require' from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `require' from /Users/shintaro/gem.repos/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb:2 ... 11 levels... from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:21:in `run' from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:15:in `each' from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:15:in `run' from /Users/shintaro/svn/rspec/trunk/bin/spec:4 ... << snip (reoccurred in other 3 specs) >> ... rake aborted! RSpec failures (See full trace by running task with --trace) ---------------------------------------------------------------------- >Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-11 01:04 Message: Is it a ZenTest's bug? --- test_help.rb.orig 2006-11-11 00:58:17.000000000 +0900 +++ test_help.rb 2006-11-11 00:58:33.000000000 +0900 @@ -1,8 +1,8 @@ # ActionPack module ActionController; end module ActionController::Flash; end -class ActionController::Flash::FlashHash; end -class ActionController::TestSession < Hash; end +class ActionController::Flash::FlashHash < Hash; end +class ActionController::TestSession; end class ActionController::TestRequest attr_accessor :session ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6608&group_id=797 From noreply at rubyforge.org Fri Nov 10 10:35:15 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 10:35:15 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6608 ] RSpec 0.7.1 with ZenTest 3.4.2 raise TypeError on TestSession Message-ID: <20061110153515.63E86524182B@rubyforge.org> Bugs item #6608, was opened at 2006-11-11 00:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6608&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) Assigned to: Nobody (None) Summary: RSpec 0.7.1 with ZenTest 3.4.2 raise TypeError on TestSession Initial Comment: ZenTest 3.4.2 defines TestSession is a Hash in their test_help.rb, althought Rails doesn't so neither pre-1.2 nor edge. I don't know why they've done that in 3.4.2 as I couldn't find ZenTest src repository... $ pwd /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails $ script/generate rspec exists spec identical spec/spec_helper.rb identical script/rails_spec identical script/rails_spec_server $ rake -q spec:app (in /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails) /Users/shintaro/gem.repos/gems/ZenTest-3.4.2/test/test_help.rb:5: superclass mismatch for class TestSession (TypeError) from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /Users/shintaro/gem.repos/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /Users/shintaro/gem.repos/gems/ZenTest-3.4.2/lib/test/rails.rb:2 from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `gem_original_require' from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `require' from /Users/shintaro/gem.repos/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb:2 ... 11 levels... from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:21:in `run' from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:15:in `each' from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:15:in `run' from /Users/shintaro/svn/rspec/trunk/bin/spec:4 ... << snip (reoccurred in other 3 specs) >> ... rake aborted! RSpec failures (See full trace by running task with --trace) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6608&group_id=797 From noreply at rubyforge.org Fri Nov 10 14:10:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 14:10:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6608 ] RSpec 0.7.1 with ZenTest 3.4.2 raise TypeError on TestSession Message-ID: <20061110191005.994885241CAA@rubyforge.org> Bugs item #6608, was opened at 2006-11-10 10:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6608&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) Assigned to: Nobody (None) Summary: RSpec 0.7.1 with ZenTest 3.4.2 raise TypeError on TestSession Initial Comment: ZenTest 3.4.2 defines TestSession is a Hash in their test_help.rb, althought Rails doesn't so neither pre-1.2 nor edge. I don't know why they've done that in 3.4.2 as I couldn't find ZenTest src repository... $ pwd /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails $ script/generate rspec exists spec identical spec/spec_helper.rb identical script/rails_spec identical script/rails_spec_server $ rake -q spec:app (in /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails) /Users/shintaro/gem.repos/gems/ZenTest-3.4.2/test/test_help.rb:5: superclass mismatch for class TestSession (TypeError) from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /Users/shintaro/gem.repos/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /Users/shintaro/gem.repos/gems/ZenTest-3.4.2/lib/test/rails.rb:2 from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `gem_original_require' from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `require' from /Users/shintaro/gem.repos/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb:2 ... 11 levels... from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:21:in `run' from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:15:in `each' from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:15:in `run' from /Users/shintaro/svn/rspec/trunk/bin/spec:4 ... << snip (reoccurred in other 3 specs) >> ... rake aborted! RSpec failures (See full trace by running task with --trace) ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-10 14:10 Message: I ran into this as well. As a (scary) workaround, I inserted this before line 5 in test_help.rb: ActionController.send(:remove_const, :TestSession) ---------------------------------------------------------------------- Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-10 11:04 Message: Is it a ZenTest's bug? --- test_help.rb.orig 2006-11-11 00:58:17.000000000 +0900 +++ test_help.rb 2006-11-11 00:58:33.000000000 +0900 @@ -1,8 +1,8 @@ # ActionPack module ActionController; end module ActionController::Flash; end -class ActionController::Flash::FlashHash; end -class ActionController::TestSession < Hash; end +class ActionController::Flash::FlashHash < Hash; end +class ActionController::TestSession; end class ActionController::TestRequest attr_accessor :session ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6608&group_id=797 From noreply at rubyforge.org Fri Nov 10 15:12:52 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 15:12:52 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6615 ] controller.should_render_rjs should support :partial => 'path/to/template' Message-ID: <20061110201252.45BAB5241CB7@rubyforge.org> Feature Requests item #6615, was opened at 2006-11-10 20:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6615&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: controller.should_render_rjs should support :partial => 'path/to/template' Initial Comment: context "Given an rjs call, a 'should_render_rjs' spec with", :context_type => :controller do controller_name :rjs_spec specify "the correct partial should pass" do post 'render_replace_html_with_partial' controller.should_render_rjs :replace_html, 'mydiv', :partial => 'rjs_spec/replacement_partial' end end ActiveSupport::JSON::CircularReferenceError in 'Given an rjs call, a 'should_render_rjs' spec with the correct partial should pass' object references itself ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6615&group_id=797 From noreply at rubyforge.org Fri Nov 10 14:55:43 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 14:55:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6608 ] RSpec 0.7.1 with ZenTest 3.4.2 raise TypeError on TestSession Message-ID: <20061110195544.19DDC5241CC1@rubyforge.org> Bugs item #6608, was opened at 2006-11-10 10:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6608&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) Assigned to: Nobody (None) Summary: RSpec 0.7.1 with ZenTest 3.4.2 raise TypeError on TestSession Initial Comment: ZenTest 3.4.2 defines TestSession is a Hash in their test_help.rb, althought Rails doesn't so neither pre-1.2 nor edge. I don't know why they've done that in 3.4.2 as I couldn't find ZenTest src repository... $ pwd /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails $ script/generate rspec exists spec identical spec/spec_helper.rb identical script/rails_spec identical script/rails_spec_server $ rake -q spec:app (in /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails) /Users/shintaro/gem.repos/gems/ZenTest-3.4.2/test/test_help.rb:5: superclass mismatch for class TestSession (TypeError) from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /Users/shintaro/gem.repos/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /Users/shintaro/gem.repos/gems/ZenTest-3.4.2/lib/test/rails.rb:2 from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `gem_original_require' from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `require' from /Users/shintaro/gem.repos/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb:2 ... 11 levels... from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:21:in `run' from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:15:in `each' from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:15:in `run' from /Users/shintaro/svn/rspec/trunk/bin/spec:4 ... << snip (reoccurred in other 3 specs) >> ... rake aborted! RSpec failures (See full trace by running task with --trace) ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-10 14:55 Message: Thanks, Shintaro for posting this: http://rubyforge.org/tracker/index.php?func=detail&aid=6610&group_id=419&atid=1678 This definitely looks like a ZenTest bug. Use ZenTest 3.4.1 until they fix it ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-10 14:10 Message: I ran into this as well. As a (scary) workaround, I inserted this before line 5 in test_help.rb: ActionController.send(:remove_const, :TestSession) ---------------------------------------------------------------------- Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-10 11:04 Message: Is it a ZenTest's bug? --- test_help.rb.orig 2006-11-11 00:58:17.000000000 +0900 +++ test_help.rb 2006-11-11 00:58:33.000000000 +0900 @@ -1,8 +1,8 @@ # ActionPack module ActionController; end module ActionController::Flash; end -class ActionController::Flash::FlashHash; end -class ActionController::TestSession < Hash; end +class ActionController::Flash::FlashHash < Hash; end +class ActionController::TestSession; end class ActionController::TestRequest attr_accessor :session ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6608&group_id=797 From luke at agileevolved.com Fri Nov 10 15:56:14 2006 From: luke at agileevolved.com (Luke Redpath) Date: Fri, 10 Nov 2006 20:56:14 +0000 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <8d961d900611090432y526194b8lc2064a73e7b6f129@mail.gmail.com> References: <5F6175DB-F05B-45E5-B97F-0AA49A5182D7@agileevolved.com> <2FAFEEA9-9435-4B66-BA66-EFB3B0CBEE64@gmail.com> <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> <84BAE719-E829-426B-9395-F40F4B0B8A66@gmail.com> <8d961d900611082033l51454023h685a553cb983499@mail.gmail.com> <8d961d900611082046v7c66a365h3c811ecab106859c@mail.gmail.com> <90DC39CC-6144-4BD3-9F55-C309A6D9642A@agileevolved.com> <8d961d900611090432y526194b8lc2064a73e7b6f129@mail.gmail.com> Message-ID: <88B4FF34-BC0B-4ABD-9A97-481AD17C1996@agileevolved.com> Now that RSpec 0.7.1 has been released, I've committed Aslak's patch to the RSpec bundle that takes advantage of the built in HTML spec format. Let me know if there are any problems. Cheers Luke From aslak.hellesoy at gmail.com Fri Nov 10 16:50:16 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 10 Nov 2006 22:50:16 +0100 Subject: [rspec-devel] Running specs with TextMate bundle In-Reply-To: <88B4FF34-BC0B-4ABD-9A97-481AD17C1996@agileevolved.com> References: <33C3E770-CB30-4691-975F-006784F20942@agileevolved.com> <8d961d900611080538t72af9651w51a82256705a6103@mail.gmail.com> <84BAE719-E829-426B-9395-F40F4B0B8A66@gmail.com> <8d961d900611082033l51454023h685a553cb983499@mail.gmail.com> <8d961d900611082046v7c66a365h3c811ecab106859c@mail.gmail.com> <90DC39CC-6144-4BD3-9F55-C309A6D9642A@agileevolved.com> <8d961d900611090432y526194b8lc2064a73e7b6f129@mail.gmail.com> <88B4FF34-BC0B-4ABD-9A97-481AD17C1996@agileevolved.com> Message-ID: <8d961d900611101350u63245749pca2cc93a99ad4feb@mail.gmail.com> On 11/10/06, Luke Redpath wrote: > Now that RSpec 0.7.1 has been released, I've committed Aslak's patch > to the RSpec bundle that takes advantage of the built in HTML spec > format. Let me know if there are any problems. > Umm. I think there has been some miscommunication here. I alredy committed it (your code + my fixes) to RSpec's svn under vendor/RSpec.tmbundle. Should I not have? Aslak > Cheers > Luke > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Fri Nov 10 16:32:10 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 16:32:10 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6615 ] controller.should_render_rjs should support :partial => 'path/to/template' Message-ID: <20061110213211.6C3EF5241CE3@rubyforge.org> Feature Requests item #6615, was opened at 2006-11-10 20:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6615&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) >Summary: controller.should_render_rjs should support :partial => 'path/to/template' Initial Comment: context "Given an rjs call, a 'should_render_rjs' spec with", :context_type => :controller do controller_name :rjs_spec specify "the correct partial should pass" do post 'render_replace_html_with_partial' controller.should_render_rjs :replace_html, 'mydiv', :partial => 'rjs_spec/replacement_partial' end end ActiveSupport::JSON::CircularReferenceError in 'Given an rjs call, a 'should_render_rjs' spec with the correct partial should pass' object references itself ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-10 21:32 Message: Fixed in trunk rev 1085 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6615&group_id=797 From noreply at rubyforge.org Fri Nov 10 16:36:19 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 16:36:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6615 ] controller.should_render_rjs should support :partial =& gt; 'path/to/template' Message-ID: <20061110213619.48E845241CE8@rubyforge.org> Feature Requests item #6615, was opened at 2006-11-10 20:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6615&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) >Summary: controller.should_render_rjs should support :partial =&gt; 'path/to/template' Initial Comment: context "Given an rjs call, a 'should_render_rjs' spec with", :context_type => :controller do controller_name :rjs_spec specify "the correct partial should pass" do post 'render_replace_html_with_partial' controller.should_render_rjs :replace_html, 'mydiv', :partial => 'rjs_spec/replacement_partial' end end ActiveSupport::JSON::CircularReferenceError in 'Given an rjs call, a 'should_render_rjs' spec with the correct partial should pass' object references itself ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-10 21:32 Message: Fixed in trunk rev 1085 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6615&group_id=797 From noreply at rubyforge.org Fri Nov 10 18:17:45 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 18:17:45 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6411 ] Can't run Rails specs with ruby Message-ID: <20061110231745.33CC8A970015@rubyforge.org> Bugs item #6411, was opened at 2006-10-30 20:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6411&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Can't run Rails specs with ruby Initial Comment: Standing in vendor/rspec_on_rails: ruby spec/models/person_spec.rb /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/expectations/sugar.rb:13:in `_method_missing' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/expectations/sugar.rb:9:in `method_missing' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/runner/context_eval.rb:37:in `method_missing' from spec/models/person_spec.rb:4 from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/runner/context.rb:14:in `initialize' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/spec/rails/context_factory.rb:17:in `create' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/kernel.rb:4:in `context' from spec/models/person_spec.rb:3 ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-10 18:17 Message: Fixed in r1088. ---------------------------------------------------------------------- Comment By: George Anderson (caton) Date: 2006-11-01 11:55 Message: I'm not sure this is isolated to running a spec via "ruby." I've tried the following (in the context of a rails app) with revsions 1000, 1004, and 1006: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~/work/stc_rl_reporting $ rake spec:models (in /Users/george/work/stc_rl_reporting) /usr/local/bin/ruby -I"/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib" "/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/bin/spec" "spec/models/report_spec.rb" "spec/models/site_spec.rb" /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `setup_parts' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_eval.rb:37:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:82:in `method_missing' from /Users/george/work/stc_rl_reporting/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:104:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/bin/spec:18 rake aborted! Command failed with status (1): [/usr/local/bin/ruby -I"/usr/local/lib/ruby...] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~/work/stc_rl_reporting $ spec spec/models/report_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `setup_parts' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_eval.rb:37:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:82:in `method_missing' from /Users/george/work/stc_rl_reporting/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:104:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/bin/spec:18 from /usr/local/bin/spec:18 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~/work/stc_rl_reporting $ ruby spec/models/report_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `setup_parts' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_eval.rb:37:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context.rb:82:in `method_missing' from /Users/george/work/stc_rl_reporting/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:104:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:25:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/context_runner.rb:24:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.0/lib/spec/runner/extensions/kernel.rb:11:in `context_runner' from spec/models/report_spec.rb:6 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It seems the issue persists whether you run via ruby, rake, or spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6411&group_id=797 From noreply at rubyforge.org Fri Nov 10 18:59:02 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 18:59:02 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6265 ] should_raise should accept an Exception object Message-ID: <20061110235902.7D2785241D1C@rubyforge.org> Feature Requests item #6265, was opened at 2006-10-21 22:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: should_raise should accept an Exception object Initial Comment: So I can pass it an exception object with the message (or anything else) set on it. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-09 01:53 Message: Reopening this. I'll try to submit a patch for this soon. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-09 01:51 Message: OK, here's a failing spec which illustrates what I'm talking about. Basically, I want to provide my own pre-created exception to be thrown, with a specified error message. require 'rubygems' require 'spec' context "a mock" do specify "should allow a pre-created exception to be raised" do error_message = "msg" e = RuntimeError.new(error_message) errormock = mock("Mock") errormock.should_receive(:method).and_raise(e) errmsg = nil begin errormock.method rescue RuntimeError => e errmsg = e.message end errmsg.should_equal(error_message) end end ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-10-23 23:51 Message: Yes, I meant "and_raise", it was a typo. I will try the Proc#should_raise and see if that works. Thanks, Chad ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-22 05:42 Message: I'm a little confused. You categorised this RFE in the mock module. RSpec mocks don't have a sould_raise method, but an and_raise method (which allows you to pass in an exception) http://rspec.rubyforge.org/documentation/mocks.html http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/mocks/mock_spec.rb?revision=931&root=rspec Or perhaps you're talking about the Proc#should_raise method? It also allows you to pass an exception object: http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/expectations/should/should_raise_spec.rb?root=rspec&view=co http://rspec.rubyforge.org/documentation/expectations.html If this doesn't work for you, please submit a failing spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 From noreply at rubyforge.org Fri Nov 10 18:40:08 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 18:40:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6616 ] Can't run Rails specs with RSpec.tmbundle Message-ID: <20061110234008.1D13B5241CE6@rubyforge.org> Bugs item #6616, was opened at 2006-11-10 18:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6616&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Can't run Rails specs with RSpec.tmbundle Initial Comment: When I try to run the demo app's person_spec.rb I get: /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./person_spec.rb:4 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context.rb:14:in `initialize' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/spec/rails/context_factory.rb:18:in `create' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/kernel.rb:4:in `context' from ./person_spec.rb:3 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in `run' from /Users/aslakhellesoy/Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:30:in `run' from /Users/aslakhellesoy/Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:8:in `run_file' from /tmp/temp_textmate.1jgrvU:4 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6616&group_id=797 From noreply at rubyforge.org Fri Nov 10 18:59:58 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 18:59:58 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6265 ] should_raise should accept an Exception object Message-ID: <20061110235958.AF4F75241D1B@rubyforge.org> Feature Requests item #6265, was opened at 2006-10-21 22:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: should_raise should accept an Exception object Initial Comment: So I can pass it an exception object with the message (or anything else) set on it. ---------------------------------------------------------------------- >Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-10 16:59 Message: Just attached a patch and passing spec for this. Works for me (tm), should be backward compatible. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-09 01:53 Message: Reopening this. I'll try to submit a patch for this soon. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-09 01:51 Message: OK, here's a failing spec which illustrates what I'm talking about. Basically, I want to provide my own pre-created exception to be thrown, with a specified error message. require 'rubygems' require 'spec' context "a mock" do specify "should allow a pre-created exception to be raised" do error_message = "msg" e = RuntimeError.new(error_message) errormock = mock("Mock") errormock.should_receive(:method).and_raise(e) errmsg = nil begin errormock.method rescue RuntimeError => e errmsg = e.message end errmsg.should_equal(error_message) end end ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-10-23 23:51 Message: Yes, I meant "and_raise", it was a typo. I will try the Proc#should_raise and see if that works. Thanks, Chad ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-22 05:42 Message: I'm a little confused. You categorised this RFE in the mock module. RSpec mocks don't have a sould_raise method, but an and_raise method (which allows you to pass in an exception) http://rspec.rubyforge.org/documentation/mocks.html http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/mocks/mock_spec.rb?revision=931&root=rspec Or perhaps you're talking about the Proc#should_raise method? It also allows you to pass an exception object: http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/expectations/should/should_raise_spec.rb?root=rspec&view=co http://rspec.rubyforge.org/documentation/expectations.html If this doesn't work for you, please submit a failing spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 From noreply at rubyforge.org Fri Nov 10 19:26:07 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 19:26:07 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6616 ] Can't run Rails specs with RSpec.tmbundle Message-ID: <20061111002607.244415241D2A@rubyforge.org> Bugs item #6616, was opened at 2006-11-10 18:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6616&group_id=797 Category: RSpec.tmbundle Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Can't run Rails specs with RSpec.tmbundle Initial Comment: When I try to run the demo app's person_spec.rb I get: /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./person_spec.rb:4 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context.rb:14:in `initialize' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/spec/rails/context_factory.rb:18:in `create' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/kernel.rb:4:in `context' from ./person_spec.rb:3 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in `run' from /Users/aslakhellesoy/Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:30:in `run' from /Users/aslakhellesoy/Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec_mate.rb:8:in `run_file' from /tmp/temp_textmate.1jgrvU:4 ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-10 19:26 Message: Fixed in r1089 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6616&group_id=797 From noreply at rubyforge.org Fri Nov 10 20:26:40 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 10 Nov 2006 20:26:40 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6265 ] should_raise should accept an Exception object Message-ID: <20061111012641.8100AA970022@rubyforge.org> Feature Requests item #6265, was opened at 2006-10-22 01:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: Chad Woolley (thewoolleyman) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: should_raise should accept an Exception object Initial Comment: So I can pass it an exception object with the message (or anything else) set on it. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-10 20:26 Message: Thanks! Fixed in r1090. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-10 18:59 Message: Just attached a patch and passing spec for this. Works for me (tm), should be backward compatible. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-09 03:53 Message: Reopening this. I'll try to submit a patch for this soon. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-11-09 03:51 Message: OK, here's a failing spec which illustrates what I'm talking about. Basically, I want to provide my own pre-created exception to be thrown, with a specified error message. require 'rubygems' require 'spec' context "a mock" do specify "should allow a pre-created exception to be raised" do error_message = "msg" e = RuntimeError.new(error_message) errormock = mock("Mock") errormock.should_receive(:method).and_raise(e) errmsg = nil begin errormock.method rescue RuntimeError => e errmsg = e.message end errmsg.should_equal(error_message) end end ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2006-10-24 02:51 Message: Yes, I meant "and_raise", it was a typo. I will try the Proc#should_raise and see if that works. Thanks, Chad ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-22 08:42 Message: I'm a little confused. You categorised this RFE in the mock module. RSpec mocks don't have a sould_raise method, but an and_raise method (which allows you to pass in an exception) http://rspec.rubyforge.org/documentation/mocks.html http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/mocks/mock_spec.rb?revision=931&root=rspec Or perhaps you're talking about the Proc#should_raise method? It also allows you to pass an exception object: http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/expectations/should/should_raise_spec.rb?root=rspec&view=co http://rspec.rubyforge.org/documentation/expectations.html If this doesn't work for you, please submit a failing spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 From noreply at rubyforge.org Sat Nov 11 16:19:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 11 Nov 2006 16:19:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6627 ] SHOWSTOPPER: ".should !=" is broken Message-ID: <20061111211957.313D65241D5B@rubyforge.org> Bugs item #6627, was opened at 2006-11-11 16:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6627&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bob Aman (sporkmonger) Assigned to: Nobody (None) Summary: SHOWSTOPPER: ".should !=" is broken Initial Comment: ".should ==" works, but ".should !=" apparently does not. This is a show-stopper for me. I've got like 300 failing specs as a result. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6627&group_id=797 From noreply at rubyforge.org Sat Nov 11 17:26:00 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 11 Nov 2006 17:26:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6627 ] SHOWSTOPPER: ".should !=" is broken Message-ID: <20061111222600.69D1E5241D6C@rubyforge.org> Bugs item #6627, was opened at 2006-11-11 21:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6627&group_id=797 >Category: expectation module Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Bob Aman (sporkmonger) >Assigned to: David Chelimsky (dchelimsky) >Summary: SHOWSTOPPER: ".should !=" is broken Initial Comment: ".should ==" works, but ".should !=" apparently does not. This is a show-stopper for me. I've got like 300 failing specs as a result. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-11 22:26 Message: http://rspec.rubyforge.org/documentation/expectations.html You should use .should_not == Unfortunately, this is a problem with the way that Ruby negates expressions. There is no way (that we found) that we are able to get a handle on the !. If you, or anyone reading this, can tackle this, we'd be glad to consider a patch. Sorry for the trouble. I'll update the upgrade page to make this more obvious. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6627&group_id=797 From noreply at rubyforge.org Sat Nov 11 17:32:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 11 Nov 2006 17:32:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6629 ] Can't run integration tests with spec-ified rails app. Message-ID: <20061111223214.0F1F65241D42@rubyforge.org> Bugs item #6629, was opened at 2006-11-11 22:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6629&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: Can't run integration tests with spec-ified rails app. Initial Comment: After installing 'spec/rails' in an app that has rails integration tests (in test/integration), running rake test does not run the tests: $ rake test:integration (in /Users/david/projects/ruby/rspec/trunk/vendor/rspec_on_rails) /usr/local/bin/ruby -Ilib:test "/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb" $ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6629&group_id=797 From aslak.hellesoy at gmail.com Sat Nov 11 20:09:43 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 12 Nov 2006 02:09:43 +0100 Subject: [rspec-devel] RSpec.tmbundle improvements Message-ID: <8d961d900611111709k47df770dh57d3e6a0efb292b0@mail.gmail.com> I have just checked in some improvements to RSpec.tmbundle, which is based on Luke Redpath's initial code. New stuff: * You can select files and/or directories and run all of those with CMD-r * There is now a real progress bar! After reading the installation instructions (for trunk HEAD): doc/src/tools/extensions/editors/textmate.page, try to open RSpec's root dir in TextMate, select the spec directory and hit CMD-r, then 'Run specifications in selected files/directories' Nice, eh? Cheers, Aslak From dchelimsky at gmail.com Sat Nov 11 20:39:25 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 11 Nov 2006 19:39:25 -0600 Subject: [rspec-devel] RSpec.tmbundle improvements In-Reply-To: <8d961d900611111709k47df770dh57d3e6a0efb292b0@mail.gmail.com> References: <8d961d900611111709k47df770dh57d3e6a0efb292b0@mail.gmail.com> Message-ID: <57c63afe0611111739gf351a38sd0ee15859f523f36@mail.gmail.com> On 11/11/06, aslak hellesoy wrote: > I have just checked in some improvements to RSpec.tmbundle, which is > based on Luke Redpath's initial code. New stuff: > > * You can select files and/or directories and run all of those with CMD-r > * There is now a real progress bar! > > After reading the installation instructions (for trunk HEAD): > doc/src/tools/extensions/editors/textmate.page, try to open RSpec's > root dir in TextMate, select the spec directory and hit CMD-r, then > 'Run specifications in selected files/directories' > > Nice, eh? WOW - this is ridiculously cool! Nicely done Luke and Aslak. > Cheers, > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sat Nov 11 19:57:28 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 11 Nov 2006 19:57:28 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6589 ] New -l --line option Message-ID: <20061112005728.8E9275241D8B@rubyforge.org> Feature Requests item #6589, was opened at 2006-11-09 19:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6589&group_id=797 Category: runner / command line Group: None >Status: Closed Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: New -l --line option Initial Comment: Having such an option would make it much easier to write external (ide/editor) extensions for RSpec. See the thread below for details (remember to add docs for this). http://rubyforge.org/pipermail/rspec-users/2006-November/000176.html ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-11 19:57 Message: Fixed. Will be in 0.7.2 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6589&group_id=797 From noreply at rubyforge.org Sun Nov 12 19:41:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 12 Nov 2006 19:41:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6643 ] script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Message-ID: <20061113004113.647425241EF7@rubyforge.org> Bugs item #6643, was opened at 2006-11-13 01:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Bakowski (dr_bonzo) Assigned to: Nobody (None) Summary: script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Initial Comment: script/generate rspec_controller generates invalid symbol (parameter of 'controller_name') for MODULARIZED (ex. Admin::UserController) controllers. Environment ----------- rails 1.1.6 rpsec 0.7.2 zentest 3.4.1 (3.4.2 does not work with this rpsec :( ) rspec_rails rev 1100 How to reproduce bug --------------------- $ rails test $ cd test $ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec $ ./script/generate rspec $ ./script/generate rspec_controller 'admin/user' list # with user of single quotes, just as help says: # Modules Example: # ./script/generate rspec_controller 'pets/dog' bark fetch $ spec spec/controllers/admin/user_controller_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `user' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./spec/controllers/admin/user_controller_spec.rb:5 The problem is with symbol for 'controller_name' generation: $ cat spec/controllers/admin/user_controller_spec.rb | grep controller_name controller_name :admin/user Changing it to: controller_name :"admin/user" or controller_name :"Admin::User" solves this problem. Spec will pass only if you set up your database.yml and create appropriate databases. -- Michal Bakowski ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 From noreply at rubyforge.org Sun Nov 12 23:23:11 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 12 Nov 2006 23:23:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6643 ] script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Message-ID: <20061113042314.8913E5241F5A@rubyforge.org> Bugs item #6643, was opened at 2006-11-13 00:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Bakowski (dr_bonzo) Assigned to: Nobody (None) Summary: script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Initial Comment: script/generate rspec_controller generates invalid symbol (parameter of 'controller_name') for MODULARIZED (ex. Admin::UserController) controllers. Environment ----------- rails 1.1.6 rpsec 0.7.2 zentest 3.4.1 (3.4.2 does not work with this rpsec :( ) rspec_rails rev 1100 How to reproduce bug --------------------- $ rails test $ cd test $ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec $ ./script/generate rspec $ ./script/generate rspec_controller 'admin/user' list # with user of single quotes, just as help says: # Modules Example: # ./script/generate rspec_controller 'pets/dog' bark fetch $ spec spec/controllers/admin/user_controller_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `user' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./spec/controllers/admin/user_controller_spec.rb:5 The problem is with symbol for 'controller_name' generation: $ cat spec/controllers/admin/user_controller_spec.rb | grep controller_name controller_name :admin/user Changing it to: controller_name :"admin/user" or controller_name :"Admin::User" solves this problem. Spec will pass only if you set up your database.yml and create appropriate databases. -- Michal Bakowski ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 04:23 Message: Now THAT is an informative report. Thank you Michal. It turns out that you can pass a String as well as a Symbol, so this might just be a matter of documentation: controller_name :unmodularized controller_name "unmodularized" controller_name "with/module" Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 From noreply at rubyforge.org Mon Nov 13 05:14:53 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 05:14:53 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6643 ] script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Message-ID: <20061113101454.060DCA970007@rubyforge.org> Bugs item #6643, was opened at 2006-11-13 01:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Bakowski (dr_bonzo) Assigned to: Nobody (None) Summary: script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Initial Comment: script/generate rspec_controller generates invalid symbol (parameter of 'controller_name') for MODULARIZED (ex. Admin::UserController) controllers. Environment ----------- rails 1.1.6 rpsec 0.7.2 zentest 3.4.1 (3.4.2 does not work with this rpsec :( ) rspec_rails rev 1100 How to reproduce bug --------------------- $ rails test $ cd test $ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec $ ./script/generate rspec $ ./script/generate rspec_controller 'admin/user' list # with user of single quotes, just as help says: # Modules Example: # ./script/generate rspec_controller 'pets/dog' bark fetch $ spec spec/controllers/admin/user_controller_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `user' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./spec/controllers/admin/user_controller_spec.rb:5 The problem is with symbol for 'controller_name' generation: $ cat spec/controllers/admin/user_controller_spec.rb | grep controller_name controller_name :admin/user Changing it to: controller_name :"admin/user" or controller_name :"Admin::User" solves this problem. Spec will pass only if you set up your database.yml and create appropriate databases. -- Michal Bakowski ---------------------------------------------------------------------- >Comment By: Michal Bakowski (dr_bonzo) Date: 2006-11-13 11:14 Message: > Now THAT is an informative report. Thanks :) > It turns out that you can pass a String as well as a Symbol, > so this might just be a matter of documentation: But the problem is with generator, it should produce correct code. $ ./script_generate rspec_controller "'with/module'" wrong constant name 'with $ also does not work. -- Michal ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 05:23 Message: Now THAT is an informative report. Thank you Michal. It turns out that you can pass a String as well as a Symbol, so this might just be a matter of documentation: controller_name :unmodularized controller_name "unmodularized" controller_name "with/module" Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 From noreply at rubyforge.org Mon Nov 13 07:47:01 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 07:47:01 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6643 ] script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Message-ID: <20061113124702.2FD9FA970007@rubyforge.org> Bugs item #6643, was opened at 2006-11-13 01:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Michal Bakowski (dr_bonzo) Assigned to: David Chelimsky (dchelimsky) Summary: script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Initial Comment: script/generate rspec_controller generates invalid symbol (parameter of 'controller_name') for MODULARIZED (ex. Admin::UserController) controllers. Environment ----------- rails 1.1.6 rpsec 0.7.2 zentest 3.4.1 (3.4.2 does not work with this rpsec :( ) rspec_rails rev 1100 How to reproduce bug --------------------- $ rails test $ cd test $ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec $ ./script/generate rspec $ ./script/generate rspec_controller 'admin/user' list # with user of single quotes, just as help says: # Modules Example: # ./script/generate rspec_controller 'pets/dog' bark fetch $ spec spec/controllers/admin/user_controller_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `user' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./spec/controllers/admin/user_controller_spec.rb:5 The problem is with symbol for 'controller_name' generation: $ cat spec/controllers/admin/user_controller_spec.rb | grep controller_name controller_name :admin/user Changing it to: controller_name :"admin/user" or controller_name :"Admin::User" solves this problem. Spec will pass only if you set up your database.yml and create appropriate databases. -- Michal Bakowski ---------------------------------------------------------------------- >Comment By: Michal Bakowski (dr_bonzo) Date: 2006-11-13 13:46 Message: Checked out trunk -- works OK now. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 13:14 Message: Right code? That's crazy!!!!!!!! Fixed in trunk revision 1102. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-13 12:35 Message: We have to make the generator generate the right code, so this is still a bug, even if spec/rails need better docs for this. ---------------------------------------------------------------------- Comment By: Michal Bakowski (dr_bonzo) Date: 2006-11-13 11:14 Message: > Now THAT is an informative report. Thanks :) > It turns out that you can pass a String as well as a Symbol, > so this might just be a matter of documentation: But the problem is with generator, it should produce correct code. $ ./script_generate rspec_controller "'with/module'" wrong constant name 'with $ also does not work. -- Michal ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 05:23 Message: Now THAT is an informative report. Thank you Michal. It turns out that you can pass a String as well as a Symbol, so this might just be a matter of documentation: controller_name :unmodularized controller_name "unmodularized" controller_name "with/module" Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 From noreply at rubyforge.org Mon Nov 13 13:40:23 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 13:40:23 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6593 ] Add moving progress bar to HtmlFormatter using Javascript Message-ID: <20061113184023.810E0A970009@rubyforge.org> Feature Requests item #6593, was opened at 2006-11-09 21:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6593&group_id=797 Category: RSpec.tmbundle Group: None >Status: Deleted Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Add moving progress bar to HtmlFormatter using Javascript Initial Comment: TDDMate (http://iamrice.org/articles/2006/02/25/edge-rails-and-tddmate) has a nifty feature to make a progress bar progress. When this is loaded slowly (by the speed of test test execution) in the browser, the HTML and Javascript will come into the browser little by little. Very useful for RSpec.tmbundle. It can be simulated by setting up a tiny WEBRick running specs (for manual testing) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6593&group_id=797 From noreply at rubyforge.org Mon Nov 13 07:14:41 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 07:14:41 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6643 ] script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Message-ID: <20061113121441.73BE4A970007@rubyforge.org> Bugs item #6643, was opened at 2006-11-13 00:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Bakowski (dr_bonzo) Assigned to: Nobody (None) Summary: script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Initial Comment: script/generate rspec_controller generates invalid symbol (parameter of 'controller_name') for MODULARIZED (ex. Admin::UserController) controllers. Environment ----------- rails 1.1.6 rpsec 0.7.2 zentest 3.4.1 (3.4.2 does not work with this rpsec :( ) rspec_rails rev 1100 How to reproduce bug --------------------- $ rails test $ cd test $ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec $ ./script/generate rspec $ ./script/generate rspec_controller 'admin/user' list # with user of single quotes, just as help says: # Modules Example: # ./script/generate rspec_controller 'pets/dog' bark fetch $ spec spec/controllers/admin/user_controller_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `user' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./spec/controllers/admin/user_controller_spec.rb:5 The problem is with symbol for 'controller_name' generation: $ cat spec/controllers/admin/user_controller_spec.rb | grep controller_name controller_name :admin/user Changing it to: controller_name :"admin/user" or controller_name :"Admin::User" solves this problem. Spec will pass only if you set up your database.yml and create appropriate databases. -- Michal Bakowski ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 12:14 Message: Right code? That's crazy!!!!!!!! Fixed in trunk revision 1102. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-13 11:35 Message: We have to make the generator generate the right code, so this is still a bug, even if spec/rails need better docs for this. ---------------------------------------------------------------------- Comment By: Michal Bakowski (dr_bonzo) Date: 2006-11-13 10:14 Message: > Now THAT is an informative report. Thanks :) > It turns out that you can pass a String as well as a Symbol, > so this might just be a matter of documentation: But the problem is with generator, it should produce correct code. $ ./script_generate rspec_controller "'with/module'" wrong constant name 'with $ also does not work. -- Michal ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 04:23 Message: Now THAT is an informative report. Thank you Michal. It turns out that you can pass a String as well as a Symbol, so this might just be a matter of documentation: controller_name :unmodularized controller_name "unmodularized" controller_name "with/module" Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 From noreply at rubyforge.org Mon Nov 13 12:53:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 12:53:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6650 ] Reserved characters in the TextMate bundle break svn on Win32 Message-ID: <20061113175350.7D6675241870@rubyforge.org> Bugs item #6650, was opened at 2006-11-13 16:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6650&group_id=797 >Category: RSpec.tmbundle Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) >Assigned to: David Chelimsky (dchelimsky) Summary: Reserved characters in the TextMate bundle break svn on Win32 Initial Comment: Here's an example 'svn up' error: A vendor\RSpec.tmbundle\Commands\Run Specifications in selected files:directo ries.tmCommand A vendor\RSpec.tmbundle\Commands\Run Specifications (SpecDoc).tmCommand svn: In directory 'vendor\RSpec.tmbundle\Commands' svn: Can't move 'vendor\RSpec.tmbundle\Commands\.svn\tmp\Run Specifications in s elected files:directories.tmCommand.tmp.tmp' to 'vendor\RSpec.tmbundle\Commands\ .svn\tmp\Run Specifications in selected files:directories.tmCommand.tmp': The fi lename, directory name, or volume label syntax is incorrect. Could someone rename that file so us Win32 people can keep up with the trunk? Here are the characters I would suggest avoiding: \ / * ? : < > | " { } ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 17:53 Message: Fixed in trunk (rev 1103) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6650&group_id=797 From noreply at rubyforge.org Mon Nov 13 07:14:56 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 07:14:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6643 ] script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Message-ID: <20061113121456.AD0B7A97000A@rubyforge.org> Bugs item #6643, was opened at 2006-11-13 00:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Michal Bakowski (dr_bonzo) >Assigned to: David Chelimsky (dchelimsky) Summary: script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Initial Comment: script/generate rspec_controller generates invalid symbol (parameter of 'controller_name') for MODULARIZED (ex. Admin::UserController) controllers. Environment ----------- rails 1.1.6 rpsec 0.7.2 zentest 3.4.1 (3.4.2 does not work with this rpsec :( ) rspec_rails rev 1100 How to reproduce bug --------------------- $ rails test $ cd test $ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec $ ./script/generate rspec $ ./script/generate rspec_controller 'admin/user' list # with user of single quotes, just as help says: # Modules Example: # ./script/generate rspec_controller 'pets/dog' bark fetch $ spec spec/controllers/admin/user_controller_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `user' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./spec/controllers/admin/user_controller_spec.rb:5 The problem is with symbol for 'controller_name' generation: $ cat spec/controllers/admin/user_controller_spec.rb | grep controller_name controller_name :admin/user Changing it to: controller_name :"admin/user" or controller_name :"Admin::User" solves this problem. Spec will pass only if you set up your database.yml and create appropriate databases. -- Michal Bakowski ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 12:14 Message: Right code? That's crazy!!!!!!!! Fixed in trunk revision 1102. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-13 11:35 Message: We have to make the generator generate the right code, so this is still a bug, even if spec/rails need better docs for this. ---------------------------------------------------------------------- Comment By: Michal Bakowski (dr_bonzo) Date: 2006-11-13 10:14 Message: > Now THAT is an informative report. Thanks :) > It turns out that you can pass a String as well as a Symbol, > so this might just be a matter of documentation: But the problem is with generator, it should produce correct code. $ ./script_generate rspec_controller "'with/module'" wrong constant name 'with $ also does not work. -- Michal ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 04:23 Message: Now THAT is an informative report. Thank you Michal. It turns out that you can pass a String as well as a Symbol, so this might just be a matter of documentation: controller_name :unmodularized controller_name "unmodularized" controller_name "with/module" Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 From noreply at rubyforge.org Mon Nov 13 13:13:30 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 13:13:30 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6650 ] Reserved characters in the TextMate bundle break svn on Win32 Message-ID: <20061113181330.237F75241870@rubyforge.org> Bugs item #6650, was opened at 2006-11-13 11:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6650&group_id=797 Category: RSpec.tmbundle Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: David Chelimsky (dchelimsky) Summary: Reserved characters in the TextMate bundle break svn on Win32 Initial Comment: Here's an example 'svn up' error: A vendor\RSpec.tmbundle\Commands\Run Specifications in selected files:directo ries.tmCommand A vendor\RSpec.tmbundle\Commands\Run Specifications (SpecDoc).tmCommand svn: In directory 'vendor\RSpec.tmbundle\Commands' svn: Can't move 'vendor\RSpec.tmbundle\Commands\.svn\tmp\Run Specifications in s elected files:directories.tmCommand.tmp.tmp' to 'vendor\RSpec.tmbundle\Commands\ .svn\tmp\Run Specifications in selected files:directories.tmCommand.tmp': The fi lename, directory name, or volume label syntax is incorrect. Could someone rename that file so us Win32 people can keep up with the trunk? Here are the characters I would suggest avoiding: \ / * ? : < > | " { } ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-13 13:13 Message: Thanks. Looks like there is still one, though: 'Run Specifications in selected files:directories.tmCommand' ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 12:53 Message: Fixed in trunk (rev 1103) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6650&group_id=797 From noreply at rubyforge.org Mon Nov 13 11:42:02 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 11:42:02 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6650 ] Reserved characters in the TextMate bundle break svn on Win32 Message-ID: <20061113164202.7BC1F52413F0@rubyforge.org> Bugs item #6650, was opened at 2006-11-13 11:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6650&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: Reserved characters in the TextMate bundle break svn on Win32 Initial Comment: Here's an example 'svn up' error: A vendor\RSpec.tmbundle\Commands\Run Specifications in selected files:directo ries.tmCommand A vendor\RSpec.tmbundle\Commands\Run Specifications (SpecDoc).tmCommand svn: In directory 'vendor\RSpec.tmbundle\Commands' svn: Can't move 'vendor\RSpec.tmbundle\Commands\.svn\tmp\Run Specifications in s elected files:directories.tmCommand.tmp.tmp' to 'vendor\RSpec.tmbundle\Commands\ .svn\tmp\Run Specifications in selected files:directories.tmCommand.tmp': The fi lename, directory name, or volume label syntax is incorrect. Could someone rename that file so us Win32 people can keep up with the trunk? Here are the characters I would suggest avoiding: \ / * ? : < > | " { } ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6650&group_id=797 From noreply at rubyforge.org Mon Nov 13 13:41:17 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 13:41:17 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6578 ] Integrate SeleniumOnRails with rspec_selenium support Message-ID: <20061113184117.DC279A970009@rubyforge.org> Feature Requests item #6578, was opened at 2006-11-08 18:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6578&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: Integrate SeleniumOnRails with rspec_selenium support Initial Comment: The idea of rspec's Selenium support is nice, but SeleniumOnRails provides some great features including the testrunner console, fixture loading, table clearing, etc. I don't know how feasible it is to integrate, since SOR uses Selenium-Core, and rspec currently uses Selenium-RC. But it's my feature request and so I get to ask for it. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-13 13:41 Message: What kind of integration are you looking for? You have to be more specific. Code please. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6578&group_id=797 From noreply at rubyforge.org Mon Nov 13 06:35:33 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 06:35:33 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6643 ] script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Message-ID: <20061113113533.A24F55241273@rubyforge.org> Bugs item #6643, was opened at 2006-11-12 19:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michal Bakowski (dr_bonzo) Assigned to: Nobody (None) Summary: script/generate rspec_controller: invalid symbol generation for 'controller_name' for *modularized* controllers Initial Comment: script/generate rspec_controller generates invalid symbol (parameter of 'controller_name') for MODULARIZED (ex. Admin::UserController) controllers. Environment ----------- rails 1.1.6 rpsec 0.7.2 zentest 3.4.1 (3.4.2 does not work with this rpsec :( ) rspec_rails rev 1100 How to reproduce bug --------------------- $ rails test $ cd test $ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec $ ./script/generate rspec $ ./script/generate rspec_controller 'admin/user' list # with user of single quotes, just as help says: # Modules Example: # ./script/generate rspec_controller 'pets/dog' bark fetch $ spec spec/controllers/admin/user_controller_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined local variable or method `user' for # (NameError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./spec/controllers/admin/user_controller_spec.rb:5 The problem is with symbol for 'controller_name' generation: $ cat spec/controllers/admin/user_controller_spec.rb | grep controller_name controller_name :admin/user Changing it to: controller_name :"admin/user" or controller_name :"Admin::User" solves this problem. Spec will pass only if you set up your database.yml and create appropriate databases. -- Michal Bakowski ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-13 06:35 Message: We have to make the generator generate the right code, so this is still a bug, even if spec/rails need better docs for this. ---------------------------------------------------------------------- Comment By: Michal Bakowski (dr_bonzo) Date: 2006-11-13 05:14 Message: > Now THAT is an informative report. Thanks :) > It turns out that you can pass a String as well as a Symbol, > so this might just be a matter of documentation: But the problem is with generator, it should produce correct code. $ ./script_generate rspec_controller "'with/module'" wrong constant name 'with $ also does not work. -- Michal ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-12 23:23 Message: Now THAT is an informative report. Thank you Michal. It turns out that you can pass a String as well as a Symbol, so this might just be a matter of documentation: controller_name :unmodularized controller_name "unmodularized" controller_name "with/module" Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6643&group_id=797 From noreply at rubyforge.org Mon Nov 13 12:53:34 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 12:53:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6650 ] Reserved characters in the TextMate bundle break svn on Win32 Message-ID: <20061113175334.B87D65241870@rubyforge.org> Bugs item #6650, was opened at 2006-11-13 16:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6650&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: Reserved characters in the TextMate bundle break svn on Win32 Initial Comment: Here's an example 'svn up' error: A vendor\RSpec.tmbundle\Commands\Run Specifications in selected files:directo ries.tmCommand A vendor\RSpec.tmbundle\Commands\Run Specifications (SpecDoc).tmCommand svn: In directory 'vendor\RSpec.tmbundle\Commands' svn: Can't move 'vendor\RSpec.tmbundle\Commands\.svn\tmp\Run Specifications in s elected files:directories.tmCommand.tmp.tmp' to 'vendor\RSpec.tmbundle\Commands\ .svn\tmp\Run Specifications in selected files:directories.tmCommand.tmp': The fi lename, directory name, or volume label syntax is incorrect. Could someone rename that file so us Win32 people can keep up with the trunk? Here are the characters I would suggest avoiding: \ / * ? : < > | " { } ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 17:53 Message: Fixed in trunk (rev 1103) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6650&group_id=797 From noreply at rubyforge.org Mon Nov 13 13:39:52 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 13:39:52 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6651 ] Ability to query whether a spec has failed or not in teardown Message-ID: <20061113183953.10F50A970009@rubyforge.org> Feature Requests item #6651, was opened at 2006-11-13 13:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6651&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Ability to query whether a spec has failed or not in teardown Initial Comment: I'm using RSpec to drive Watir. When a spec fails, I want to take a screenshot before closing the browser in teardown. (Screenshotting is supported by Watir). Example: teardown do if failed? screenshot_file_name = "#{context_name} #{spec_name}.jpg".gsub!(/\s/, "_") screen_capture(screenshot, true) end @ie.close end 3 new methods that need to be available in teardown: failed? context_name spec_name ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6651&group_id=797 From noreply at rubyforge.org Mon Nov 13 17:51:52 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 13 Nov 2006 17:51:52 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6650 ] Reserved characters in the TextMate bundle break svn on Win32 Message-ID: <20061113225153.0D7955241949@rubyforge.org> Bugs item #6650, was opened at 2006-11-13 16:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6650&group_id=797 Category: RSpec.tmbundle Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: David Chelimsky (dchelimsky) Summary: Reserved characters in the TextMate bundle break svn on Win32 Initial Comment: Here's an example 'svn up' error: A vendor\RSpec.tmbundle\Commands\Run Specifications in selected files:directo ries.tmCommand A vendor\RSpec.tmbundle\Commands\Run Specifications (SpecDoc).tmCommand svn: In directory 'vendor\RSpec.tmbundle\Commands' svn: Can't move 'vendor\RSpec.tmbundle\Commands\.svn\tmp\Run Specifications in s elected files:directories.tmCommand.tmp.tmp' to 'vendor\RSpec.tmbundle\Commands\ .svn\tmp\Run Specifications in selected files:directories.tmCommand.tmp': The fi lename, directory name, or volume label syntax is incorrect. Could someone rename that file so us Win32 people can keep up with the trunk? Here are the characters I would suggest avoiding: \ / * ? : < > | " { } ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 22:51 Message: Got it - rev 1104. Thanks for your patience! ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-13 18:13 Message: Thanks. Looks like there is still one, though: 'Run Specifications in selected files:directories.tmCommand' ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-13 17:53 Message: Fixed in trunk (rev 1103) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6650&group_id=797 From pergesu at gmail.com Tue Nov 14 23:25:04 2006 From: pergesu at gmail.com (Pat Maddox) Date: Tue, 14 Nov 2006 21:25:04 -0700 Subject: [rspec-devel] Edge RSpec on Rails Message-ID: <810a540e0611142025o5c2db22epe6d8e0177d2e3d56@mail.gmail.com> For anyone that wants to use edge RSpec on their Rails project, it's really easy. I put it up at http://www.flpr.org/2006/11/15/edge-rspec-on-rails From pergesu at gmail.com Tue Nov 14 23:27:32 2006 From: pergesu at gmail.com (Pat Maddox) Date: Tue, 14 Nov 2006 21:27:32 -0700 Subject: [rspec-devel] Edge RSpec on Rails Message-ID: <810a540e0611142027r7a49f85dx737c5a72042e056@mail.gmail.com> For anyone that wants to use edge RSpec on their Rails project, it's really easy. I put it up at http://www.flpr.org/2006/11/15/edge-rspec-on-rails From dchelimsky at gmail.com Wed Nov 15 05:41:46 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 15 Nov 2006 05:41:46 -0500 Subject: [rspec-devel] Edge RSpec on Rails In-Reply-To: <810a540e0611142027r7a49f85dx737c5a72042e056@mail.gmail.com> References: <810a540e0611142027r7a49f85dx737c5a72042e056@mail.gmail.com> Message-ID: <57c63afe0611150241g543cb929y7ca50800de48db0d@mail.gmail.com> Hi Pat, Thanks for posting this. re "Only problem I've found is that the rake tasks aren't being recognized by Rails, but they haven't worked for me since the move to 0.7.2 anyway, I think." - do you mean that the RSpec rake tasks aren't being recognized by Rails or that w/ the plugin installed your OTHER tasks aren't being recognized? Would you please submit a bug for this w/ some details? Thanks, David On 11/14/06, Pat Maddox wrote: > For anyone that wants to use edge RSpec on their Rails project, it's > really easy. I put it up at > http://www.flpr.org/2006/11/15/edge-rspec-on-rails > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From petrilli at gmail.com Wed Nov 15 08:25:35 2006 From: petrilli at gmail.com (Christopher Petrilli) Date: Wed, 15 Nov 2006 08:25:35 -0500 Subject: [rspec-devel] Integrating autotest support into Rspec on Rails Message-ID: <59d991c40611150525n21a2a326mba4be5cd20065deb@mail.gmail.com> I admit it, I'm an autotest[1] junkie, and suffer withdrawals when I have to code without it. A while back, Nick Seiger posted some extra code[2] to allow you to use autotest with RSpec and Rails, but it's a bit of a kludge. I'm wondering if this is something that the RSpec on Rails plugin might want to include? Or, is it something I should try and stuff into another plugin so it doesn't confuse those who have yet to get a taste of the addiction? Chris [1] http://www.zenspider.com/ZSS/Products/ZenTest/ [2] http://blog.nicksieger.com/articles/2006/09/13/auto-rspec -- | Christopher Petrilli | petrilli at gmail.com From bkeepers at gmail.com Wed Nov 15 08:53:29 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Wed, 15 Nov 2006 08:53:29 -0500 Subject: [rspec-devel] Edge RSpec on Rails In-Reply-To: <57c63afe0611150241g543cb929y7ca50800de48db0d@mail.gmail.com> References: <810a540e0611142027r7a49f85dx737c5a72042e056@mail.gmail.com> <57c63afe0611150241g543cb929y7ca50800de48db0d@mail.gmail.com> Message-ID: <31E248EF-9843-46F8-A422-EC87D1CD3D0A@gmail.com> On Nov 15, 2006, at 5:41 AM, David Chelimsky wrote: > Hi Pat, > > Thanks for posting this. > > re "Only problem I've found is that the rake tasks aren't being > recognized by Rails, but they haven't worked for me since the move to > 0.7.2 anyway, I think." I experienced this same problem yesterday when I tried to symlink to the rspec plugin instead of copying it into my plugins directory. The rspec tasks just don't show up. > - do you mean that the RSpec rake tasks aren't > being recognized by Rails or that w/ the plugin installed your OTHER > tasks aren't being recognized? Would you please submit a bug for this > w/ some details? > > Thanks, > David Brandon From nicksieger at gmail.com Wed Nov 15 10:34:44 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 15 Nov 2006 09:34:44 -0600 Subject: [rspec-devel] Integrating autotest support into Rspec on Rails In-Reply-To: <59d991c40611150525n21a2a326mba4be5cd20065deb@mail.gmail.com> References: <59d991c40611150525n21a2a326mba4be5cd20065deb@mail.gmail.com> Message-ID: On 11/15/06, Christopher Petrilli wrote: > > I admit it, I'm an autotest[1] junkie, and suffer withdrawals when I > have to code without it. A while back, Nick Seiger posted some extra > code[2] to allow you to use autotest with RSpec and Rails, but it's a > bit of a kludge. I'm wondering if this is something that the RSpec on > Rails plugin might want to include? > > Or, is it something I should try and stuff into another plugin so it > doesn't confuse those who have yet to get a taste of the addiction? Actually, making this a plugin is a good idea. Remove any existing remnants you have and try this out: script/plugin install http://svn.caldersphere.net/svn/main/plugins/rspec_autotest It's probably best to keep it this way for now, unless the RSpec or ZenTest guys can see a better way of integrating this in. Cheers, /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061115/bc9ae29c/attachment.html From noreply at rubyforge.org Wed Nov 15 11:08:19 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 11:08:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115160819.BA3715241F6B@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 09:06:20 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 09:06:20 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115140620.A72ED52419D8@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Tue Nov 14 20:00:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 14 Nov 2006 20:00:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115010050.3619EA970019@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 06:30:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 06:30:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115113013.761F05241946@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 09:26:06 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 09:26:06 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115142606.4A9545241B95@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 06:22:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 06:22:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115112205.5DF555241668@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 11:10:18 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 11:10:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115161020.5D61B5241F79@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 11:53:47 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 11:53:47 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115165348.7E5FC5240EE4@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 16:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From trotter at eastmedia.com Wed Nov 15 12:25:56 2006 From: trotter at eastmedia.com (Trotter Cashion) Date: Wed, 15 Nov 2006 12:25:56 -0500 Subject: [rspec-devel] Monkey patch for Test::Rails with latest Edge Rails Message-ID: Everyone, The latest version of Edge Rails raises an error when deprecated instance variables are set. Test::Rails touches @session when rendering views, causing specs to blow up. Put the monkey patch below into your spec_helper to fix this problem. I'm posting it on this list because I don't know when this will be patched in Test::Rails, and I figure some of you may run into this error soon. in spec/spec_helper.rb module Test module Rails class ViewTestCase < ViewTestCase.superclass attr_reader :session alias_method :setup_with_session_instance_variable, :setup def setup setup_with_session_instance_variable @controller.send(:remove_instance_variable, "@session".to_sym) @session = @controller.session end end end end - Trotter From dchelimsky at gmail.com Wed Nov 15 12:56:51 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 15 Nov 2006 12:56:51 -0500 Subject: [rspec-devel] Monkey patch for Test::Rails with latest Edge Rails In-Reply-To: References: Message-ID: <57c63afe0611150956v6f21cb25jcd628f6f57b7e6f0@mail.gmail.com> On 11/15/06, Trotter Cashion wrote: > Everyone, > > The latest version of Edge Rails raises an error when deprecated > instance variables are set. Test::Rails touches @session when > rendering views, causing specs to blow up. Put the monkey patch below > into your spec_helper to fix this problem. I'm posting it on this > list because I don't know when this will be patched in Test::Rails, > and I figure some of you may run into this error soon. > > in spec/spec_helper.rb > > module Test > module Rails > class ViewTestCase < ViewTestCase.superclass > attr_reader :session > alias_method :setup_with_session_instance_variable, :setup > def setup > setup_with_session_instance_variable > @controller.send(:remove_instance_variable, "@session".to_sym) > @session = @controller.session > end > end > end > end Thanks Trotter. Just an FYI to the list - I'm in the process of yanking the dependency on ZenTest. We only use it to provide the separation and there is a ton of other stuff like assertions and auditing that we don't want as part of RSpec (different mentality), and it's going to be hard enough to stay current w/ Rails, much less other libraries in the middle. So we'll grab/learn what we need from Zen, include their license and call it a day. To be clear, this is not meant to be a dis on ZenTest. What it does is awesome. It's just a very different approach from what we're trying to encourage w/ rspec. Cheers, David > > - Trotter > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From trotter at eastmedia.com Wed Nov 15 12:57:41 2006 From: trotter at eastmedia.com (Trotter Cashion) Date: Wed, 15 Nov 2006 12:57:41 -0500 Subject: [rspec-devel] Monkey patch for Test::Rails with latest Edge Rails In-Reply-To: References: Message-ID: Oh, remove "< ViewTestCase.superclass" if you want. That's just me doing stupid stuff and playing around. - Trotter On Nov 15, 2006, at 12:25 PM, Trotter Cashion wrote: > Everyone, > > The latest version of Edge Rails raises an error when deprecated > instance variables are set. Test::Rails touches @session when > rendering views, causing specs to blow up. Put the monkey patch below > into your spec_helper to fix this problem. I'm posting it on this > list because I don't know when this will be patched in Test::Rails, > and I figure some of you may run into this error soon. > > in spec/spec_helper.rb > > module Test > module Rails > class ViewTestCase < ViewTestCase.superclass > attr_reader :session > alias_method :setup_with_session_instance_variable, :setup > def setup > setup_with_session_instance_variable > @controller.send(:remove_instance_variable, > "@session".to_sym) > @session = @controller.session > end > end > end > end > > - Trotter > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Wed Nov 15 16:56:44 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 16:56:44 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115215644.D87A45241FCD@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 17:10:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 17:10:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115221014.E40D55241FC0@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 17:36:31 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 17:36:31 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115223632.2236D5241FE5@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 22:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 22:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 21:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 16:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 18:48:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 18:48:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061115234826.6C2815242011@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 19:02:11 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 19:02:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116000211.7717A524201B@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 23:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 22:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 22:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 21:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 16:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 19:10:19 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 19:10:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116001019.72581524201B@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 23:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 22:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 22:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 21:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 16:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 19:25:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 19:25:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116002557.E566A524202F@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 19:28:42 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 19:28:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116002843.28EF15242029@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 19:36:27 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 19:36:27 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116003627.DB822524202E@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 20:41:40 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 20:41:40 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6317 ] c option for colorizing output does not work with rails_spec Message-ID: <20061116014140.7DB99524204F@rubyforge.org> Bugs item #6317, was opened at 2006-10-26 07:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6317&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ed Howland (edhowland) Assigned to: Nobody (None) Summary: c option for colorizing output does not work with rails_spec Initial Comment: When using the -c, --color or --colur option with rails_spec (the sever client) the output is black, not red or green as in using rhe normal spec command. ---------------------------------------------------------------------- Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-16 10:41 Message: How about following patches. It's not smart, but works. Index: lib/spec/runner/formatter/base_text_formatter.rb =================================================================== --- lib/spec/runner/formatter/base_text_formatter.rb (revision 1111) +++ lib/spec/runner/formatter/base_text_formatter.rb (working copy) @@ -100,6 +100,14 @@ "#{colour_code}#{text}\e[0m" end + def output_to_stdout? + begin + @output == Kernel || @output.stdout? + rescue NoMethodError + false + end + end + def red(text); colour(text, "\e[31m"); end def green(text); colour(text, "\e[32m"); end def magenta(text); colour(text, "\e[35m"); end @@ -107,4 +115,4 @@ end end end -end \ No newline at end of file +end Index: vendor/rspec_on_rails/vendor/plugins/rspec/generators/rspec/templates/script/rails_spec =================================================================== --- vendor/rspec_on_rails/vendor/plugins/rspec/generators/rspec/templates/script/rails_spec (revision 1111) +++ vendor/rspec_on_rails/vendor/plugins/rspec/generators/rspec/templates/script/rails_spec (working copy) @@ -5,7 +5,10 @@ begin DRb.start_service rails_spec_server = DRbObject.new_with_uri("druby://localhost:8989") + STDOUT.instance_eval do + def stdout?; self == STDOUT end + end rails_spec_server.run(ARGV, STDERR, STDOUT) rescue DRb::DRbConnError puts "No rails_spec_server is running. Please start one via 'script/rails_spec_server'" -end \ No newline at end of file +end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6317&group_id=797 From noreply at rubyforge.org Wed Nov 15 21:12:59 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 21:12:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116021302.665665242049@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 02:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 00:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 23:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 22:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 22:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 21:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 16:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 22:57:45 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 22:57:45 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116035746.07684524208B@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 22:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 21:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 22:59:53 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 22:59:53 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6317 ] c option for colorizing output does not work with rails_spec Message-ID: <20061116035953.5569F5242099@rubyforge.org> Bugs item #6317, was opened at 2006-10-26 07:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6317&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ed Howland (edhowland) Assigned to: Nobody (None) Summary: c option for colorizing output does not work with rails_spec Initial Comment: When using the -c, --color or --colur option with rails_spec (the sever client) the output is black, not red or green as in using rhe normal spec command. ---------------------------------------------------------------------- Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-16 12:59 Message: following patch is better than the last post? Index: lib/spec/runner/formatter/base_text_formatter.rb =================================================================== --- lib/spec/runner/formatter/base_text_formatter.rb (revision 1114) +++ lib/spec/runner/formatter/base_text_formatter.rb (working copy) @@ -96,10 +96,18 @@ end def colour(text, colour_code) - return text unless @colour && @output == Kernel + return text unless @colour && output_to_stdout? "#{colour_code}#{text}\e[0m" end + def output_to_stdout? + begin + @output == Kernel || @output.tty? + rescue NoMethodError + false + end + end + def red(text); colour(text, "\e[31m"); end def green(text); colour(text, "\e[32m"); end def magenta(text); colour(text, "\e[35m"); end @@ -107,4 +115,4 @@ end end end -end \ No newline at end of file +end ---------------------------------------------------------------------- Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-16 10:41 Message: How about following patches. It's not smart, but works. Index: lib/spec/runner/formatter/base_text_formatter.rb =================================================================== --- lib/spec/runner/formatter/base_text_formatter.rb (revision 1111) +++ lib/spec/runner/formatter/base_text_formatter.rb (working copy) @@ -100,6 +100,14 @@ "#{colour_code}#{text}\e[0m" end + def output_to_stdout? + begin + @output == Kernel || @output.stdout? + rescue NoMethodError + false + end + end + def red(text); colour(text, "\e[31m"); end def green(text); colour(text, "\e[32m"); end def magenta(text); colour(text, "\e[35m"); end @@ -107,4 +115,4 @@ end end end -end \ No newline at end of file +end Index: vendor/rspec_on_rails/vendor/plugins/rspec/generators/rspec/templates/script/rails_spec =================================================================== --- vendor/rspec_on_rails/vendor/plugins/rspec/generators/rspec/templates/script/rails_spec (revision 1111) +++ vendor/rspec_on_rails/vendor/plugins/rspec/generators/rspec/templates/script/rails_spec (working copy) @@ -5,7 +5,10 @@ begin DRb.start_service rails_spec_server = DRbObject.new_with_uri("druby://localhost:8989") + STDOUT.instance_eval do + def stdout?; self == STDOUT end + end rails_spec_server.run(ARGV, STDERR, STDOUT) rescue DRb::DRbConnError puts "No rails_spec_server is running. Please start one via 'script/rails_spec_server'" -end \ No newline at end of file +end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6317&group_id=797 From noreply at rubyforge.org Wed Nov 15 23:24:14 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 23:24:14 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116042414.654B3524209B@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 04:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 03:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 02:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 00:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 23:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 22:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 22:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 21:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 16:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 23:31:08 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 23:31:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116043108.23CB6524209B@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 23:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 22:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 21:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 23:46:02 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 23:46:02 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116044602.66259524209F@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 23:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 23:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 22:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 21:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Wed Nov 15 23:54:28 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Nov 2006 23:54:28 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116045428.9452152420AB@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 23:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 23:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 22:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 21:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From bkeepers at gmail.com Thu Nov 16 01:52:31 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Thu, 16 Nov 2006 01:52:31 -0500 Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} In-Reply-To: <20061116045428.9452152420AB@rubyforge.org> References: <20061116045428.9452152420AB@rubyforge.org> Message-ID: Rubyforge appears to be down at the moment, so I'll just put this in an email for now. Wilson, sorry, but I couldn't wait. I went ahead and came up with an implementation of should_change. It was actually really simple...once I got acquainted with the rspec internals. Attached is a patch. Let me know what you think. The messages could use some love, and are we worried about what happens if someone calls #to, #from, or #by without having first called #should_change? Brandon -------------- next part -------------- A non-text attachment was scrubbed... Name: should_change.patch Type: application/octet-stream Size: 5533 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061116/7d0253b7/attachment-0001.obj -------------- next part -------------- On Nov 15, 2006, at 11:54 PM, wrote: > Patches item #6417, was opened at 2006-10-31 16:36 > You can respond by visiting: > http://rubyforge.org/tracker/? > func=detail&atid=3151&aid=6417&group_id=797 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 3 > Submitted By: Wilson Bilkovich (wilson) > Assigned to: Nobody (None) > Summary: [PATCH] Support @object.some_method_should_be_changed_by > {block} > > Initial Comment: > I was toying with how to implement the RSpec equivalent of > "assert_difference" from test/unit. > > In case you haven't used it, it looks something like this: > > assert_difference some_object, :some_method { some code here } > > > > It calls some_object.some_method before and after the block, and > fails if there is no difference. > > > > This patch implements something similarly generic: > > > > @some_object.some_method_should_be_changed_by {|obj| code here} > > ..and its inverse: > > @some_object.some_method_should_not_be_changed_by {|obj| code here} > > > > some_method is stripped from the beginning of the message, and > passed forward for use inside the Should module. > > > > Has specs, and all other existing specs still pass. > > > > A real 'use case' example: > > > > User.count_should_be_changed_by do > > User.create :login => 'quentin', :email => 'blah at example.com'... > > end > > > > User.count will be different before and after, so this expectation > will be met. > > ---------------------------------------------------------------------- > >> Comment By: Wilson Bilkovich (wilson) > Date: 2006-11-15 23:54 > > Message: > One piece of trickery I haven't managed to think my way > > through yet is.. > > If we want to support should_change().to("val") > > ..how can we support the bare should_change() call? > > If it needs to proxy for the 'to' and 'from' calls, how do > > we know there aren't more messages changed onto the end? > > > > The semi-equivalent 'Have' syntax seems to have avoided this > > by requiring a suffix method in every case. > > There's no: > > @thing.should_have(5) > > ..only @thing.should_have(5).things > > ---------------------------------------------------------------------- > > Comment By: Brandon Keepers (brandon) > Date: 2006-11-15 23:46 > > Message: > I agree with David. I actually really like this syntax. It feels > very natural. > > > > lambda { ... }.should_change(obj, :method).to("val") > > > > ---------------------------------------------------------------------- > > Comment By: Wilson Bilkovich (wilson) > Date: 2006-11-15 23:31 > > Message: > Yeah, that and call_stack doesn't seem to work the way I'd > > expect: > > http://rpaste.com/pastes/575 > > > > I made some progress with set_trace_func, but oh lord is it > > slow. > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2006-11-15 23:24 > > Message: > I don't think the syntax is *much* nicer, but that's really a > subjective thing :) > > > > I'd prefer the previous options because they align better w/ other > constructs like should_raise and should_throw that we already use > for blocks. I'd also like to avoid any dependencies unless they buy > us a lot. > > ---------------------------------------------------------------------- > > Comment By: Wilson Bilkovich (wilson) > Date: 2006-11-15 22:57 > > Message: > Hrm. Just saw this: > > http://eigenclass.org/hiki.rb?call_stack > > > > It is possible that I can use that to implement the much > > nicer syntax: > > > > User.count.should_be_changed.by {block} > > User.count.should_be_changed.from(x).to(y).by {block} > > > > How do we feel about a dependency on that, or something similar? > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2006-11-15 21:12 > > Message: > The proc will be @target, so just do this: > > > > @target.call > > > > Syntax? I like .to(x), .from(y) and .by(z) because it feels more > like most of the rest of rspec. It'll also result in a more OO > implementation. > > > > Consensus? Don't see one yet, but you have my recommendation. > > > > Cheers, > > David > > ---------------------------------------------------------------------- > > Comment By: Wilson Bilkovich (wilson) > Date: 2006-11-15 19:36 > > Message: > So, what is the consensus? > > > > specify "should take some discussion to get right" do > > proc{User.create :name => 'Bob'}.should_change(User, :count) > > > > proc{User.noop}.should_not_change(User, :count) > > end > > > > specify "should be fairly tricky" do > > proc{User.create :name => 'Bob'}.should_change(User, > > :count).by(1) > > end > > > > The 'by' version strikes me as a little domain-specific. It > > only works with values that support subtraction. > > > > > > Implementation-wise, how do I make the should proxy call the > > proc/lambda? Do we already have something like > > binding_of_caller in here? > > > > I also thing I slightly prefer the :to => and :from => > > version (an options Hash), though I will admit that that's > > partly because it is easier to implement. It avoids needing > > to subclass Should. > > ---------------------------------------------------------------------- > > Comment By: Brandon Keepers (brandon) > Date: 2006-11-15 19:28 > > Message: > And, just so we don't forget: > > > > { ... }.should_not_change(@tim, :name) > > ---------------------------------------------------------------------- > > Comment By: Brandon Keepers (brandon) > Date: 2006-11-15 19:25 > > Message: > Good discussions! I'm really excited about this feature. > > > > I'm grasping at straws here because I don't know how the Rspec > internals are implemented, but what if should_change(@tim, :name) > actually called the proc and simply stored the before and after > values, then #from, #to, and #by just called expectations on those > references? Then, all forms would work regardless of order? > > > > # @before.should_not == @after > > { ... }.should_change(@tim, :name) > > > > # @before.should_not == @after > > # @after.should == "Larry" > > { ... }.should_change(@tim, :name).to("Larry") > > > > # @before.should_not == @after > > # @before.should == "Tim" > > # @after.should == "Larry" > > { ... }.should_change(@tim, :name).from("Tim").to("Larry") > > { ... }.should_change(@tim, :name).to("Larry").from("Tim") > > > > # @before.should_not == @after > > # @before.should == @after + -1 > > { ... }.should_change(User, :count).by(-1) > > > > Would that work? > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2006-11-15 19:10 > > Message: > Wilson - this was your baby originally. You want to resubmit a patch? > > > > Also, I'm on the fence re: syntax per my last comment. We *could* > do this: > > > > should_change(@tim, :name).to("Larry") > > should_change(@tim, :name).from('Tim').to('Larry') > > should_change(@tim, :age).by(1) > > > > If we call the proc on 'to' or 'by'. The nice thing about the other > syntax is that it doesn't matter if you screw up the order: > > > > should_change(@time, :name, :to => 'Larry', :from => Tim); > > should_change(@time, :name, :from => 'Tim', :to => 'Larry'); > > > > Those would behave the same way, whereas: > > > > should_change(@tim, :name).from('Tim').to('Larry') > > should_change(@tim, :name).to('Larry').from('Tim') > > > > would not. It also supports simply: > > > > should_change(@time, :name) > > > > without any specifics. Less declarative, true, but it becomes the > developers choice. > > > > Let us know if you want to submit a patch, and if you do if you > want some direction. Otherwise we'll add this sometime soon. > > > > Cheers, > > David > > > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2006-11-15 19:02 > > Message: > I like the less verbose one, though that would be up to the developer. > > > > This aligns well w/ other expectations like: > > > > lambda {...}.should_raise > > lambda {...}.should_return (RFE 6187) > > > > I agree that we should add it now. And I think we should support > the following forms: > > > > should_change(@tim, :name).to("Larry") > > should_change(@tim, :name).from('Tim').to('Larry') > > should_change(@tim, :age).by(1) > > > > Ah - but the middle one won't work because we won't know when to > call the proc. > > > > How about this? > > > > should_change(@time, :name, :to => 'Larry'); > > should_change(@time, :name, :from => 'Tim', :to => 'Larry'); > > should_change(@time, :age, :by => 1); > > > > The reason I want from/to is to specify the value going in and > coming out. I think that's more explicit. > > > > Thoughts? > > ---------------------------------------------------------------------- > > Comment By: Aslak Helles?y (aslak_hellesoy) > Date: 2006-11-15 18:48 > > Message: > Right, it's not @tim changing his name, it's *something*. How about: > > > > lambda do > > ... > > end.should_change(@tim, :name).to("Larry") > > > > or slightly more readable (but more verbose): > > > > updating_tim = lambda do > > # do the post or whatever > > end > > updating_tim.should_change(@tim, :name).to("Larry") > > > > That's more aligned with the mocking syntax. I do think this is > very much aligned with BDD. It provides a way to specify some > general outcome (or observable behaviour) of an arbitrary chunk of > code. I like it. > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2006-11-15 17:36 > > Message: > This syntax is definitely better, though it's still a bit awkward > in the sense that it reads like we're saying that @tim should be > responsible for changing his name, as opposed to "after this > action, @tim's name should have been changed" (by whom, we don't > know or care). > > > > It's the best we've got so far. > > > > Aslak - do you have any thoughts as to the BDD-ness of this? It > seems to me that it's got a different structure from what we've > been recommending (i.e. context goes in setup - here context is > implied within specify), but it also seems very behaviour oriented > (BOP?????). > > > > Thoughts? > > ---------------------------------------------------------------------- > > Comment By: Aslak Helles?y (aslak_hellesoy) > Date: 2006-11-15 17:10 > > Message: > I like that syntax! > > > > However, the last example might not work so well with Rails. > Consider this: > > > > @tim.should_change(:name).to("Larry") do > > post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} > > end > > > > It will probably update tim in the database, but it won't change > the @tim reference. You'll have to reload tim. Perhaps this would > work: > > > > @tim.should_change(:name).to("Larry") do > > post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} > > @tim.reload > > end > > > > Yeah, that should work I think. > > > > ---------------------------------------------------------------------- > > Comment By: Brandon Keepers (brandon) > Date: 2006-11-15 16:56 > > Message: > What about this syntax: > > > > # non-deterministic > > User.should_change(:count) { ... } > > > > # increment/decrement > > User.should_change(:count).by(1) { ... } > > User.should_change(:count).by(-1) { ... } > > > > # verify that name changed and the new value should == "Larry" > > @tim.should_change(:name).to("Larry") { ... } > > # verify before and after > > @tim.should_change(:name).from("Tim").to("Larry") { ... } > > > > I haven't really thought about if the implementation of these would > work. I like that it doesn't use past tense and makes it feel more > like setting up the mock expectations instead of verifying after- > the-fact, which conceptually is more what this is doing. > > > > Thoughts? > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2006-11-15 11:53 > > Message: > I'd stay away from sugar. Sugar is only there to intercept messages > that start with "should_", hence the implementation. > > > > I do see the dilemma re: getting a handle on the User rather than > the value it returns for :count. Agreed that > User.should_return_different_results_for(:count).after { > > block here } is clunky, but I think that's the right direction. Not > sure of a better way to do it though. > > > > As for the plugin requiring a change for every release, that's only > temporary. We do plan to address plugins and extensions because we > want people to feel free to publish extensions. > > ---------------------------------------------------------------------- > > Comment By: Wilson Bilkovich (wilson) > Date: 2006-11-15 11:10 > > Message: > Oh, and Brandon's example: > > > > User.count.should_be_changed_by(1) { User.create(...) } > > > > ..is, as far as I can tell, impossible to implement without > > modifying the Ruby interpreter. > > If User.count starts out at 5, 'should' is being called on > > an instance of Fixnum. There's no way to tell what value to > > compare it to, after the block returns. > > ---------------------------------------------------------------------- > > Comment By: Wilson Bilkovich (wilson) > Date: 2006-11-15 11:08 > > Message: > That's precisely why I implemented it this way. I would much > > prefer to be able to write: > > User.count.should_be_changed..etc.etc.. > > ..but without a way to get a handle on the "method that was > > called to return the object that should was called on", I > > couldn't think of another way. > > > > Also, re: sugar.rb > > Here's a line of code from trunk: > > return original_method_missing.bind(self).call(sym, *args, > > &block) unless sym.to_s =~ /^should_/ > > As you can see, sugar assumes that the message being > > intercepted begins with 'should'. Because this patch > > requires a different behavior, I will still need to > > monkey-patch sugar.rb. > > > > I'm happy to do this as a plugin, it just looks like I would > > need to release a new version almost every time the trunk > > changed. > > > > The other way to implement this would be something like: > > User.should_return_different_results_for(:count).after { > > block here} > > > > ..but that seems clunky. I like the way this version reads, > > myself. > > ---------------------------------------------------------------------- > > Comment By: Brandon Keepers (brandon) > Date: 2006-11-15 09:26 > > Message: > Ok, looking into this a little, I see why it is implemented how it > is. The idea is that you want to check that the result of a method > call is changed by a block, not necessarily the referenced object > itself. It happens to work if the referenced object is being > modified, but what about when it's just being re-assigned? > > > > For example, this would work because :count is being incremented: > > > > User.count.should_be_changed_by(1) { User.create(...) } > > > > But, this would fail: > > > > @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } > > > > should_be_changed_to is looking that the referenced variable > changes, but in the block, I'm just reassigning it, so the original > reference to name is not modified. > > > > Thoughts? > > ---------------------------------------------------------------------- > > Comment By: Brandon Keepers (brandon) > Date: 2006-11-15 09:06 > > Message: > So, the main issue is just the implementation, and not the feature > itself? I agree with you about it being too non-deterministic. > > > > I like the examples that you gave, it feels more like original the > assert_difference. > > > > I'd also like to see "should_be_changed_to(newval)" > > > > Maybe I'll get myself familiar with the rspec internals and > actually contribute instead of standing on the sidelines. ;) > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2006-11-15 06:30 > > Message: > Brandon - re: inclusion as a core feature: > > > > I think it is too non-deterministic as/is. In the example, one > could override (accidentally, of course) User.create to delete > something and the spec would pass. > > > > We *could* make it more deterministic: > > > > User.count.should_be_changed_by('+ 1') do {...} > > > > or > > > > User.count.should_be_changed_from(3).to(4) do {...} > > > > One thing that concerns me is that we lose the separation between > context and outcome that is essential to BDD. > > > > Although it is very behavioral in nature. I'm on the fence. > > > > Thoughts? > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2006-11-15 06:22 > > Message: > Wilson - re: your question about plugins and sugar: > > > > sugar.rb now only intercepts the :should_ part of > a :should_do_something message. What you want to extend is the > Should class itself (in this case with a 'changed_by' method that > takes a block), and the Not class if you want a negative counterpart. > > > > Be forewarned that we're not committing to the current structure at > this point, so you'd be incurring some risk that a future version > of RSpec might break your plugin because you're patching something > internal. We will, however, at some point soon (within a month or > two I think), publish (and thereby commit to) an entry point to > extending expectations. > > ---------------------------------------------------------------------- > > Comment By: Brandon Keepers (brandon) > Date: 2006-11-14 20:00 > > Message: > What is the reasoning for not including this as a core feature? > This is a very helpful expectation. > > ---------------------------------------------------------------------- > > Comment By: Aslak Helles?y (aslak_hellesoy) > Date: 2006-11-06 13:11 > > Message: > I don't think anyone has thought much about how a plugin mechanism > will actually be implemented. We'll try as hard as we can to make > something forward compatible and easy to use. > > > > Your patch here would be a good case to verify a plugin mechanism > against. > > > > I actually implemented this very feature a couple of months ago > (rel 0.5.14). We decided to remove the day after. The thread about > it starts here: > > > > http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html > > > > ---------------------------------------------------------------------- > > Comment By: Wilson Bilkovich (wilson) > Date: 2006-11-06 12:51 > > Message: > Hrm. Are plugins going to be able to modify sugar.rb in a > > forward-compatible way? > > I'm not sure how to implement this without stepping in that > > early in the chain. > > ---------------------------------------------------------------------- > > Comment By: Aslak Helles?y (aslak_hellesoy) > Date: 2006-11-06 12:45 > > Message: > I think this is the kind of stuff we'd encourage people to bundle > as an RSpec plugin. We don't have a plugin mechanism yet, but we'll > hopefully have one soon. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://rubyforge.org/tracker/? > func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Thu Nov 16 09:42:29 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 09:42:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6706 ] controller generator doesn't handle controllers in subdirectories perfectly Message-ID: <20061116144229.BED00A970001@rubyforge.org> Bugs item #6706, was opened at 2006-11-16 09:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6706&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: controller generator doesn't handle controllers in subdirectories perfectly Initial Comment: for example running: script/generate rspec_controller admin/some_controller creates the files and folders as you would expect the only issue is within the generated rb file you get controller_name :admin/some_controller which throws an error: undefined local variable or method `some_controller' for # Bugs item #6707, was opened at 2006-11-16 09:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6707&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: cannot run controller / helper tests via rails_spec or spec only works with rake Initial Comment: I've tried four methods for running rails specs and here are the results for 0.7.2 (plugin and gem) on windows ruby spec/controllers/admin/some_controller_spec.rb - WORKS but not sure if supposed to do things this way? spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for (NoMethodError) Start rails_spec_server then ruby script\rails_spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for (NoMethodError) (SAME AS BEFORE) rake spec - WORKS FINE --- the sample test --- require File.dirname(__FILE__) + '/../../spec_helper' context "The Admin::TalentPoolsController" do # fixtures :talent_pools controller_name "admin/talent_pools" specify "should be a Admin::TalentPoolsController" do controller.should_be_an_instance_of Admin::TalentPoolsController end specify "should have more specifications" do violated "not enough specs" end end --- It seems that the module that contains the class method for controller_name does not get loaded except with rake / ruby? we really need the test suite not to reload each time (current rake takes 25 minutes or longer!) --- the same error happens with helpers and the call to helper_name ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6707&group_id=797 From bkeepers at gmail.com Thu Nov 16 10:06:20 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Thu, 16 Nov 2006 10:06:20 -0500 Subject: [rspec-devel] [PATCH] should_change In-Reply-To: References: <20061116045428.9452152420AB@rubyforge.org> Message-ID: I forgot to add support for chaining #to and #from. Here's an updated patch. Any thoughts? Brandon -------------- next part -------------- A non-text attachment was scrubbed... Name: should_change.patch Type: application/octet-stream Size: 6176 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061116/a8bc4306/attachment-0001.obj -------------- next part -------------- On Nov 16, 2006, at 1:52 AM, Brandon Keepers wrote: > Rubyforge appears to be down at the moment, so I'll just put this > in an email for now. > > Wilson, sorry, but I couldn't wait. I went ahead and came up with > an implementation of should_change. It was actually really > simple...once I got acquainted with the rspec internals. Attached > is a patch. > > Let me know what you think. The messages could use some love, and > are we worried about what happens if someone calls #to, #from, or > #by without having first called #should_change? > > Brandon > > > > On Nov 15, 2006, at 11:54 PM, wrote: > >> Patches item #6417, was opened at 2006-10-31 16:36 >> You can respond by visiting: >> http://rubyforge.org/tracker/? >> func=detail&atid=3151&aid=6417&group_id=797 >> >> Category: None >> Group: None >> Status: Open >> Resolution: None >> Priority: 3 >> Submitted By: Wilson Bilkovich (wilson) >> Assigned to: Nobody (None) >> Summary: [PATCH] Support @object.some_method_should_be_changed_by >> {block} >> >> Initial Comment: >> I was toying with how to implement the RSpec equivalent of >> "assert_difference" from test/unit. >> >> In case you haven't used it, it looks something like this: >> >> assert_difference some_object, :some_method { some code here } >> >> >> >> It calls some_object.some_method before and after the block, and >> fails if there is no difference. >> >> >> >> This patch implements something similarly generic: >> >> >> >> @some_object.some_method_should_be_changed_by {|obj| code here} >> >> ..and its inverse: >> >> @some_object.some_method_should_not_be_changed_by {|obj| code here} >> >> >> >> some_method is stripped from the beginning of the message, and >> passed forward for use inside the Should module. >> >> >> >> Has specs, and all other existing specs still pass. >> >> >> >> A real 'use case' example: >> >> >> >> User.count_should_be_changed_by do >> >> User.create :login => 'quentin', :email => 'blah at example.com'... >> >> end >> >> >> >> User.count will be different before and after, so this expectation >> will be met. >> >> --------------------------------------------------------------------- >> - >> >>> Comment By: Wilson Bilkovich (wilson) >> Date: 2006-11-15 23:54 >> >> Message: >> One piece of trickery I haven't managed to think my way >> >> through yet is.. >> >> If we want to support should_change().to("val") >> >> ..how can we support the bare should_change() call? >> >> If it needs to proxy for the 'to' and 'from' calls, how do >> >> we know there aren't more messages changed onto the end? >> >> >> >> The semi-equivalent 'Have' syntax seems to have avoided this >> >> by requiring a suffix method in every case. >> >> There's no: >> >> @thing.should_have(5) >> >> ..only @thing.should_have(5).things >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Brandon Keepers (brandon) >> Date: 2006-11-15 23:46 >> >> Message: >> I agree with David. I actually really like this syntax. It feels >> very natural. >> >> >> >> lambda { ... }.should_change(obj, :method).to("val") >> >> >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Wilson Bilkovich (wilson) >> Date: 2006-11-15 23:31 >> >> Message: >> Yeah, that and call_stack doesn't seem to work the way I'd >> >> expect: >> >> http://rpaste.com/pastes/575 >> >> >> >> I made some progress with set_trace_func, but oh lord is it >> >> slow. >> >> --------------------------------------------------------------------- >> - >> >> Comment By: David Chelimsky (dchelimsky) >> Date: 2006-11-15 23:24 >> >> Message: >> I don't think the syntax is *much* nicer, but that's really a >> subjective thing :) >> >> >> >> I'd prefer the previous options because they align better w/ other >> constructs like should_raise and should_throw that we already use >> for blocks. I'd also like to avoid any dependencies unless they >> buy us a lot. >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Wilson Bilkovich (wilson) >> Date: 2006-11-15 22:57 >> >> Message: >> Hrm. Just saw this: >> >> http://eigenclass.org/hiki.rb?call_stack >> >> >> >> It is possible that I can use that to implement the much >> >> nicer syntax: >> >> >> >> User.count.should_be_changed.by {block} >> >> User.count.should_be_changed.from(x).to(y).by {block} >> >> >> >> How do we feel about a dependency on that, or something similar? >> >> --------------------------------------------------------------------- >> - >> >> Comment By: David Chelimsky (dchelimsky) >> Date: 2006-11-15 21:12 >> >> Message: >> The proc will be @target, so just do this: >> >> >> >> @target.call >> >> >> >> Syntax? I like .to(x), .from(y) and .by(z) because it feels more >> like most of the rest of rspec. It'll also result in a more OO >> implementation. >> >> >> >> Consensus? Don't see one yet, but you have my recommendation. >> >> >> >> Cheers, >> >> David >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Wilson Bilkovich (wilson) >> Date: 2006-11-15 19:36 >> >> Message: >> So, what is the consensus? >> >> >> >> specify "should take some discussion to get right" do >> >> proc{User.create :name => 'Bob'}.should_change(User, :count) >> >> >> >> proc{User.noop}.should_not_change(User, :count) >> >> end >> >> >> >> specify "should be fairly tricky" do >> >> proc{User.create :name => 'Bob'}.should_change(User, >> >> :count).by(1) >> >> end >> >> >> >> The 'by' version strikes me as a little domain-specific. It >> >> only works with values that support subtraction. >> >> >> >> >> >> Implementation-wise, how do I make the should proxy call the >> >> proc/lambda? Do we already have something like >> >> binding_of_caller in here? >> >> >> >> I also thing I slightly prefer the :to => and :from => >> >> version (an options Hash), though I will admit that that's >> >> partly because it is easier to implement. It avoids needing >> >> to subclass Should. >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Brandon Keepers (brandon) >> Date: 2006-11-15 19:28 >> >> Message: >> And, just so we don't forget: >> >> >> >> { ... }.should_not_change(@tim, :name) >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Brandon Keepers (brandon) >> Date: 2006-11-15 19:25 >> >> Message: >> Good discussions! I'm really excited about this feature. >> >> >> >> I'm grasping at straws here because I don't know how the Rspec >> internals are implemented, but what if should_change(@tim, :name) >> actually called the proc and simply stored the before and after >> values, then #from, #to, and #by just called expectations on those >> references? Then, all forms would work regardless of order? >> >> >> >> # @before.should_not == @after >> >> { ... }.should_change(@tim, :name) >> >> >> >> # @before.should_not == @after >> >> # @after.should == "Larry" >> >> { ... }.should_change(@tim, :name).to("Larry") >> >> >> >> # @before.should_not == @after >> >> # @before.should == "Tim" >> >> # @after.should == "Larry" >> >> { ... }.should_change(@tim, :name).from("Tim").to("Larry") >> >> { ... }.should_change(@tim, :name).to("Larry").from("Tim") >> >> >> >> # @before.should_not == @after >> >> # @before.should == @after + -1 >> >> { ... }.should_change(User, :count).by(-1) >> >> >> >> Would that work? >> >> --------------------------------------------------------------------- >> - >> >> Comment By: David Chelimsky (dchelimsky) >> Date: 2006-11-15 19:10 >> >> Message: >> Wilson - this was your baby originally. You want to resubmit a patch? >> >> >> >> Also, I'm on the fence re: syntax per my last comment. We *could* >> do this: >> >> >> >> should_change(@tim, :name).to("Larry") >> >> should_change(@tim, :name).from('Tim').to('Larry') >> >> should_change(@tim, :age).by(1) >> >> >> >> If we call the proc on 'to' or 'by'. The nice thing about the >> other syntax is that it doesn't matter if you screw up the order: >> >> >> >> should_change(@time, :name, :to => 'Larry', :from => Tim); >> >> should_change(@time, :name, :from => 'Tim', :to => 'Larry'); >> >> >> >> Those would behave the same way, whereas: >> >> >> >> should_change(@tim, :name).from('Tim').to('Larry') >> >> should_change(@tim, :name).to('Larry').from('Tim') >> >> >> >> would not. It also supports simply: >> >> >> >> should_change(@time, :name) >> >> >> >> without any specifics. Less declarative, true, but it becomes the >> developers choice. >> >> >> >> Let us know if you want to submit a patch, and if you do if you >> want some direction. Otherwise we'll add this sometime soon. >> >> >> >> Cheers, >> >> David >> >> >> >> --------------------------------------------------------------------- >> - >> >> Comment By: David Chelimsky (dchelimsky) >> Date: 2006-11-15 19:02 >> >> Message: >> I like the less verbose one, though that would be up to the >> developer. >> >> >> >> This aligns well w/ other expectations like: >> >> >> >> lambda {...}.should_raise >> >> lambda {...}.should_return (RFE 6187) >> >> >> >> I agree that we should add it now. And I think we should support >> the following forms: >> >> >> >> should_change(@tim, :name).to("Larry") >> >> should_change(@tim, :name).from('Tim').to('Larry') >> >> should_change(@tim, :age).by(1) >> >> >> >> Ah - but the middle one won't work because we won't know when to >> call the proc. >> >> >> >> How about this? >> >> >> >> should_change(@time, :name, :to => 'Larry'); >> >> should_change(@time, :name, :from => 'Tim', :to => 'Larry'); >> >> should_change(@time, :age, :by => 1); >> >> >> >> The reason I want from/to is to specify the value going in and >> coming out. I think that's more explicit. >> >> >> >> Thoughts? >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Aslak Helles?y (aslak_hellesoy) >> Date: 2006-11-15 18:48 >> >> Message: >> Right, it's not @tim changing his name, it's *something*. How about: >> >> >> >> lambda do >> >> ... >> >> end.should_change(@tim, :name).to("Larry") >> >> >> >> or slightly more readable (but more verbose): >> >> >> >> updating_tim = lambda do >> >> # do the post or whatever >> >> end >> >> updating_tim.should_change(@tim, :name).to("Larry") >> >> >> >> That's more aligned with the mocking syntax. I do think this is >> very much aligned with BDD. It provides a way to specify some >> general outcome (or observable behaviour) of an arbitrary chunk of >> code. I like it. >> >> --------------------------------------------------------------------- >> - >> >> Comment By: David Chelimsky (dchelimsky) >> Date: 2006-11-15 17:36 >> >> Message: >> This syntax is definitely better, though it's still a bit awkward >> in the sense that it reads like we're saying that @tim should be >> responsible for changing his name, as opposed to "after this >> action, @tim's name should have been changed" (by whom, we don't >> know or care). >> >> >> >> It's the best we've got so far. >> >> >> >> Aslak - do you have any thoughts as to the BDD-ness of this? It >> seems to me that it's got a different structure from what we've >> been recommending (i.e. context goes in setup - here context is >> implied within specify), but it also seems very behaviour oriented >> (BOP?????). >> >> >> >> Thoughts? >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Aslak Helles?y (aslak_hellesoy) >> Date: 2006-11-15 17:10 >> >> Message: >> I like that syntax! >> >> >> >> However, the last example might not work so well with Rails. >> Consider this: >> >> >> >> @tim.should_change(:name).to("Larry") do >> >> post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} >> >> end >> >> >> >> It will probably update tim in the database, but it won't change >> the @tim reference. You'll have to reload tim. Perhaps this would >> work: >> >> >> >> @tim.should_change(:name).to("Larry") do >> >> post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} >> >> @tim.reload >> >> end >> >> >> >> Yeah, that should work I think. >> >> >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Brandon Keepers (brandon) >> Date: 2006-11-15 16:56 >> >> Message: >> What about this syntax: >> >> >> >> # non-deterministic >> >> User.should_change(:count) { ... } >> >> >> >> # increment/decrement >> >> User.should_change(:count).by(1) { ... } >> >> User.should_change(:count).by(-1) { ... } >> >> >> >> # verify that name changed and the new value should == "Larry" >> >> @tim.should_change(:name).to("Larry") { ... } >> >> # verify before and after >> >> @tim.should_change(:name).from("Tim").to("Larry") { ... } >> >> >> >> I haven't really thought about if the implementation of these >> would work. I like that it doesn't use past tense and makes it >> feel more like setting up the mock expectations instead of >> verifying after-the-fact, which conceptually is more what this is >> doing. >> >> >> >> Thoughts? >> >> --------------------------------------------------------------------- >> - >> >> Comment By: David Chelimsky (dchelimsky) >> Date: 2006-11-15 11:53 >> >> Message: >> I'd stay away from sugar. Sugar is only there to intercept >> messages that start with "should_", hence the implementation. >> >> >> >> I do see the dilemma re: getting a handle on the User rather than >> the value it returns for :count. Agreed that >> User.should_return_different_results_for(:count).after { >> >> block here } is clunky, but I think that's the right direction. >> Not sure of a better way to do it though. >> >> >> >> As for the plugin requiring a change for every release, that's >> only temporary. We do plan to address plugins and extensions >> because we want people to feel free to publish extensions. >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Wilson Bilkovich (wilson) >> Date: 2006-11-15 11:10 >> >> Message: >> Oh, and Brandon's example: >> >> >> >> User.count.should_be_changed_by(1) { User.create(...) } >> >> >> >> ..is, as far as I can tell, impossible to implement without >> >> modifying the Ruby interpreter. >> >> If User.count starts out at 5, 'should' is being called on >> >> an instance of Fixnum. There's no way to tell what value to >> >> compare it to, after the block returns. >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Wilson Bilkovich (wilson) >> Date: 2006-11-15 11:08 >> >> Message: >> That's precisely why I implemented it this way. I would much >> >> prefer to be able to write: >> >> User.count.should_be_changed..etc.etc.. >> >> ..but without a way to get a handle on the "method that was >> >> called to return the object that should was called on", I >> >> couldn't think of another way. >> >> >> >> Also, re: sugar.rb >> >> Here's a line of code from trunk: >> >> return original_method_missing.bind(self).call(sym, *args, >> >> &block) unless sym.to_s =~ /^should_/ >> >> As you can see, sugar assumes that the message being >> >> intercepted begins with 'should'. Because this patch >> >> requires a different behavior, I will still need to >> >> monkey-patch sugar.rb. >> >> >> >> I'm happy to do this as a plugin, it just looks like I would >> >> need to release a new version almost every time the trunk >> >> changed. >> >> >> >> The other way to implement this would be something like: >> >> User.should_return_different_results_for(:count).after { >> >> block here} >> >> >> >> ..but that seems clunky. I like the way this version reads, >> >> myself. >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Brandon Keepers (brandon) >> Date: 2006-11-15 09:26 >> >> Message: >> Ok, looking into this a little, I see why it is implemented how it >> is. The idea is that you want to check that the result of a >> method call is changed by a block, not necessarily the referenced >> object itself. It happens to work if the referenced object is >> being modified, but what about when it's just being re-assigned? >> >> >> >> For example, this would work because :count is being incremented: >> >> >> >> User.count.should_be_changed_by(1) { User.create(...) } >> >> >> >> But, this would fail: >> >> >> >> @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } >> >> >> >> should_be_changed_to is looking that the referenced variable >> changes, but in the block, I'm just reassigning it, so the >> original reference to name is not modified. >> >> >> >> Thoughts? >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Brandon Keepers (brandon) >> Date: 2006-11-15 09:06 >> >> Message: >> So, the main issue is just the implementation, and not the feature >> itself? I agree with you about it being too non-deterministic. >> >> >> >> I like the examples that you gave, it feels more like original the >> assert_difference. >> >> >> >> I'd also like to see "should_be_changed_to(newval)" >> >> >> >> Maybe I'll get myself familiar with the rspec internals and >> actually contribute instead of standing on the sidelines. ;) >> >> --------------------------------------------------------------------- >> - >> >> Comment By: David Chelimsky (dchelimsky) >> Date: 2006-11-15 06:30 >> >> Message: >> Brandon - re: inclusion as a core feature: >> >> >> >> I think it is too non-deterministic as/is. In the example, one >> could override (accidentally, of course) User.create to delete >> something and the spec would pass. >> >> >> >> We *could* make it more deterministic: >> >> >> >> User.count.should_be_changed_by('+ 1') do {...} >> >> >> >> or >> >> >> >> User.count.should_be_changed_from(3).to(4) do {...} >> >> >> >> One thing that concerns me is that we lose the separation between >> context and outcome that is essential to BDD. >> >> >> >> Although it is very behavioral in nature. I'm on the fence. >> >> >> >> Thoughts? >> >> --------------------------------------------------------------------- >> - >> >> Comment By: David Chelimsky (dchelimsky) >> Date: 2006-11-15 06:22 >> >> Message: >> Wilson - re: your question about plugins and sugar: >> >> >> >> sugar.rb now only intercepts the :should_ part of >> a :should_do_something message. What you want to extend is the >> Should class itself (in this case with a 'changed_by' method that >> takes a block), and the Not class if you want a negative counterpart. >> >> >> >> Be forewarned that we're not committing to the current structure >> at this point, so you'd be incurring some risk that a future >> version of RSpec might break your plugin because you're patching >> something internal. We will, however, at some point soon (within a >> month or two I think), publish (and thereby commit to) an entry >> point to extending expectations. >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Brandon Keepers (brandon) >> Date: 2006-11-14 20:00 >> >> Message: >> What is the reasoning for not including this as a core feature? >> This is a very helpful expectation. >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Aslak Helles?y (aslak_hellesoy) >> Date: 2006-11-06 13:11 >> >> Message: >> I don't think anyone has thought much about how a plugin mechanism >> will actually be implemented. We'll try as hard as we can to make >> something forward compatible and easy to use. >> >> >> >> Your patch here would be a good case to verify a plugin mechanism >> against. >> >> >> >> I actually implemented this very feature a couple of months ago >> (rel 0.5.14). We decided to remove the day after. The thread about >> it starts here: >> >> >> >> http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html >> >> >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Wilson Bilkovich (wilson) >> Date: 2006-11-06 12:51 >> >> Message: >> Hrm. Are plugins going to be able to modify sugar.rb in a >> >> forward-compatible way? >> >> I'm not sure how to implement this without stepping in that >> >> early in the chain. >> >> --------------------------------------------------------------------- >> - >> >> Comment By: Aslak Helles?y (aslak_hellesoy) >> Date: 2006-11-06 12:45 >> >> Message: >> I think this is the kind of stuff we'd encourage people to bundle >> as an RSpec plugin. We don't have a plugin mechanism yet, but >> we'll hopefully have one soon. >> >> --------------------------------------------------------------------- >> - >> >> You can respond by visiting: >> http://rubyforge.org/tracker/? >> func=detail&atid=3151&aid=6417&group_id=797 > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061116/a8bc4306/attachment-0001.bin From noreply at rubyforge.org Thu Nov 16 11:13:45 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 11:13:45 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6706 ] controller generator doesn't handle controllers in subdirectories perfectly Message-ID: <20061116161346.21B7AA970011@rubyforge.org> Bugs item #6706, was opened at 2006-11-16 14:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6706&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Nobody (None) >Assigned to: David Chelimsky (dchelimsky) Summary: controller generator doesn't handle controllers in subdirectories perfectly Initial Comment: for example running: script/generate rspec_controller admin/some_controller creates the files and folders as you would expect the only issue is within the generated rb file you get controller_name :admin/some_controller which throws an error: undefined local variable or method `some_controller' for #Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 16:13 Message: This is already fixed in the trunk and will be released with 0.7.3. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6706&group_id=797 From dchelimsky at gmail.com Thu Nov 16 11:21:15 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 16 Nov 2006 10:21:15 -0600 Subject: [rspec-devel] [PATCH] should_change In-Reply-To: References: <20061116045428.9452152420AB@rubyforge.org> Message-ID: <57c63afe0611160821y596a0ce3w5e884194944db2d0@mail.gmail.com> On first glance this looks great. I'll take a closer look tonight. The only thing I might do differently would be to add a Change class (like Have) so the to, from, and by methods don't clutter up Should. Nice work! David On 11/16/06, Brandon Keepers wrote: > I forgot to add support for chaining #to and #from. Here's an > updated patch. Any thoughts? > > Brandon > > > From wilsonb at gmail.com Thu Nov 16 11:27:54 2006 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Thu, 16 Nov 2006 11:27:54 -0500 Subject: [rspec-devel] [PATCH] should_change In-Reply-To: References: <20061116045428.9452152420AB@rubyforge.org> Message-ID: I like it. The way I've got mine, the "from" and "to" methods are only available after the "should_change" returns. If that's worth having, I'm happy to finish mine out. On 11/16/06, Brandon Keepers wrote: > I forgot to add support for chaining #to and #from. Here's an > updated patch. Any thoughts? > > Brandon > > > > > On Nov 16, 2006, at 1:52 AM, Brandon Keepers wrote: > > > Rubyforge appears to be down at the moment, so I'll just put this > > in an email for now. > > > > Wilson, sorry, but I couldn't wait. I went ahead and came up with > > an implementation of should_change. It was actually really > > simple...once I got acquainted with the rspec internals. Attached > > is a patch. > > > > Let me know what you think. The messages could use some love, and > > are we worried about what happens if someone calls #to, #from, or > > #by without having first called #should_change? > > > > Brandon > > > > > > > > On Nov 15, 2006, at 11:54 PM, wrote: > > > >> Patches item #6417, was opened at 2006-10-31 16:36 > >> You can respond by visiting: > >> http://rubyforge.org/tracker/? > >> func=detail&atid=3151&aid=6417&group_id=797 > >> > >> Category: None > >> Group: None > >> Status: Open > >> Resolution: None > >> Priority: 3 > >> Submitted By: Wilson Bilkovich (wilson) > >> Assigned to: Nobody (None) > >> Summary: [PATCH] Support @object.some_method_should_be_changed_by > >> {block} > >> > >> Initial Comment: > >> I was toying with how to implement the RSpec equivalent of > >> "assert_difference" from test/unit. > >> > >> In case you haven't used it, it looks something like this: > >> > >> assert_difference some_object, :some_method { some code here } > >> > >> > >> > >> It calls some_object.some_method before and after the block, and > >> fails if there is no difference. > >> > >> > >> > >> This patch implements something similarly generic: > >> > >> > >> > >> @some_object.some_method_should_be_changed_by {|obj| code here} > >> > >> ..and its inverse: > >> > >> @some_object.some_method_should_not_be_changed_by {|obj| code here} > >> > >> > >> > >> some_method is stripped from the beginning of the message, and > >> passed forward for use inside the Should module. > >> > >> > >> > >> Has specs, and all other existing specs still pass. > >> > >> > >> > >> A real 'use case' example: > >> > >> > >> > >> User.count_should_be_changed_by do > >> > >> User.create :login => 'quentin', :email => 'blah at example.com'... > >> > >> end > >> > >> > >> > >> User.count will be different before and after, so this expectation > >> will be met. > >> > >> --------------------------------------------------------------------- > >> - > >> > >>> Comment By: Wilson Bilkovich (wilson) > >> Date: 2006-11-15 23:54 > >> > >> Message: > >> One piece of trickery I haven't managed to think my way > >> > >> through yet is.. > >> > >> If we want to support should_change().to("val") > >> > >> ..how can we support the bare should_change() call? > >> > >> If it needs to proxy for the 'to' and 'from' calls, how do > >> > >> we know there aren't more messages changed onto the end? > >> > >> > >> > >> The semi-equivalent 'Have' syntax seems to have avoided this > >> > >> by requiring a suffix method in every case. > >> > >> There's no: > >> > >> @thing.should_have(5) > >> > >> ..only @thing.should_have(5).things > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Brandon Keepers (brandon) > >> Date: 2006-11-15 23:46 > >> > >> Message: > >> I agree with David. I actually really like this syntax. It feels > >> very natural. > >> > >> > >> > >> lambda { ... }.should_change(obj, :method).to("val") > >> > >> > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Wilson Bilkovich (wilson) > >> Date: 2006-11-15 23:31 > >> > >> Message: > >> Yeah, that and call_stack doesn't seem to work the way I'd > >> > >> expect: > >> > >> http://rpaste.com/pastes/575 > >> > >> > >> > >> I made some progress with set_trace_func, but oh lord is it > >> > >> slow. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: David Chelimsky (dchelimsky) > >> Date: 2006-11-15 23:24 > >> > >> Message: > >> I don't think the syntax is *much* nicer, but that's really a > >> subjective thing :) > >> > >> > >> > >> I'd prefer the previous options because they align better w/ other > >> constructs like should_raise and should_throw that we already use > >> for blocks. I'd also like to avoid any dependencies unless they > >> buy us a lot. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Wilson Bilkovich (wilson) > >> Date: 2006-11-15 22:57 > >> > >> Message: > >> Hrm. Just saw this: > >> > >> http://eigenclass.org/hiki.rb?call_stack > >> > >> > >> > >> It is possible that I can use that to implement the much > >> > >> nicer syntax: > >> > >> > >> > >> User.count.should_be_changed.by {block} > >> > >> User.count.should_be_changed.from(x).to(y).by {block} > >> > >> > >> > >> How do we feel about a dependency on that, or something similar? > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: David Chelimsky (dchelimsky) > >> Date: 2006-11-15 21:12 > >> > >> Message: > >> The proc will be @target, so just do this: > >> > >> > >> > >> @target.call > >> > >> > >> > >> Syntax? I like .to(x), .from(y) and .by(z) because it feels more > >> like most of the rest of rspec. It'll also result in a more OO > >> implementation. > >> > >> > >> > >> Consensus? Don't see one yet, but you have my recommendation. > >> > >> > >> > >> Cheers, > >> > >> David > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Wilson Bilkovich (wilson) > >> Date: 2006-11-15 19:36 > >> > >> Message: > >> So, what is the consensus? > >> > >> > >> > >> specify "should take some discussion to get right" do > >> > >> proc{User.create :name => 'Bob'}.should_change(User, :count) > >> > >> > >> > >> proc{User.noop}.should_not_change(User, :count) > >> > >> end > >> > >> > >> > >> specify "should be fairly tricky" do > >> > >> proc{User.create :name => 'Bob'}.should_change(User, > >> > >> :count).by(1) > >> > >> end > >> > >> > >> > >> The 'by' version strikes me as a little domain-specific. It > >> > >> only works with values that support subtraction. > >> > >> > >> > >> > >> > >> Implementation-wise, how do I make the should proxy call the > >> > >> proc/lambda? Do we already have something like > >> > >> binding_of_caller in here? > >> > >> > >> > >> I also thing I slightly prefer the :to => and :from => > >> > >> version (an options Hash), though I will admit that that's > >> > >> partly because it is easier to implement. It avoids needing > >> > >> to subclass Should. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Brandon Keepers (brandon) > >> Date: 2006-11-15 19:28 > >> > >> Message: > >> And, just so we don't forget: > >> > >> > >> > >> { ... }.should_not_change(@tim, :name) > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Brandon Keepers (brandon) > >> Date: 2006-11-15 19:25 > >> > >> Message: > >> Good discussions! I'm really excited about this feature. > >> > >> > >> > >> I'm grasping at straws here because I don't know how the Rspec > >> internals are implemented, but what if should_change(@tim, :name) > >> actually called the proc and simply stored the before and after > >> values, then #from, #to, and #by just called expectations on those > >> references? Then, all forms would work regardless of order? > >> > >> > >> > >> # @before.should_not == @after > >> > >> { ... }.should_change(@tim, :name) > >> > >> > >> > >> # @before.should_not == @after > >> > >> # @after.should == "Larry" > >> > >> { ... }.should_change(@tim, :name).to("Larry") > >> > >> > >> > >> # @before.should_not == @after > >> > >> # @before.should == "Tim" > >> > >> # @after.should == "Larry" > >> > >> { ... }.should_change(@tim, :name).from("Tim").to("Larry") > >> > >> { ... }.should_change(@tim, :name).to("Larry").from("Tim") > >> > >> > >> > >> # @before.should_not == @after > >> > >> # @before.should == @after + -1 > >> > >> { ... }.should_change(User, :count).by(-1) > >> > >> > >> > >> Would that work? > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: David Chelimsky (dchelimsky) > >> Date: 2006-11-15 19:10 > >> > >> Message: > >> Wilson - this was your baby originally. You want to resubmit a patch? > >> > >> > >> > >> Also, I'm on the fence re: syntax per my last comment. We *could* > >> do this: > >> > >> > >> > >> should_change(@tim, :name).to("Larry") > >> > >> should_change(@tim, :name).from('Tim').to('Larry') > >> > >> should_change(@tim, :age).by(1) > >> > >> > >> > >> If we call the proc on 'to' or 'by'. The nice thing about the > >> other syntax is that it doesn't matter if you screw up the order: > >> > >> > >> > >> should_change(@time, :name, :to => 'Larry', :from => Tim); > >> > >> should_change(@time, :name, :from => 'Tim', :to => 'Larry'); > >> > >> > >> > >> Those would behave the same way, whereas: > >> > >> > >> > >> should_change(@tim, :name).from('Tim').to('Larry') > >> > >> should_change(@tim, :name).to('Larry').from('Tim') > >> > >> > >> > >> would not. It also supports simply: > >> > >> > >> > >> should_change(@time, :name) > >> > >> > >> > >> without any specifics. Less declarative, true, but it becomes the > >> developers choice. > >> > >> > >> > >> Let us know if you want to submit a patch, and if you do if you > >> want some direction. Otherwise we'll add this sometime soon. > >> > >> > >> > >> Cheers, > >> > >> David > >> > >> > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: David Chelimsky (dchelimsky) > >> Date: 2006-11-15 19:02 > >> > >> Message: > >> I like the less verbose one, though that would be up to the > >> developer. > >> > >> > >> > >> This aligns well w/ other expectations like: > >> > >> > >> > >> lambda {...}.should_raise > >> > >> lambda {...}.should_return (RFE 6187) > >> > >> > >> > >> I agree that we should add it now. And I think we should support > >> the following forms: > >> > >> > >> > >> should_change(@tim, :name).to("Larry") > >> > >> should_change(@tim, :name).from('Tim').to('Larry') > >> > >> should_change(@tim, :age).by(1) > >> > >> > >> > >> Ah - but the middle one won't work because we won't know when to > >> call the proc. > >> > >> > >> > >> How about this? > >> > >> > >> > >> should_change(@time, :name, :to => 'Larry'); > >> > >> should_change(@time, :name, :from => 'Tim', :to => 'Larry'); > >> > >> should_change(@time, :age, :by => 1); > >> > >> > >> > >> The reason I want from/to is to specify the value going in and > >> coming out. I think that's more explicit. > >> > >> > >> > >> Thoughts? > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Aslak Helles?y (aslak_hellesoy) > >> Date: 2006-11-15 18:48 > >> > >> Message: > >> Right, it's not @tim changing his name, it's *something*. How about: > >> > >> > >> > >> lambda do > >> > >> ... > >> > >> end.should_change(@tim, :name).to("Larry") > >> > >> > >> > >> or slightly more readable (but more verbose): > >> > >> > >> > >> updating_tim = lambda do > >> > >> # do the post or whatever > >> > >> end > >> > >> updating_tim.should_change(@tim, :name).to("Larry") > >> > >> > >> > >> That's more aligned with the mocking syntax. I do think this is > >> very much aligned with BDD. It provides a way to specify some > >> general outcome (or observable behaviour) of an arbitrary chunk of > >> code. I like it. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: David Chelimsky (dchelimsky) > >> Date: 2006-11-15 17:36 > >> > >> Message: > >> This syntax is definitely better, though it's still a bit awkward > >> in the sense that it reads like we're saying that @tim should be > >> responsible for changing his name, as opposed to "after this > >> action, @tim's name should have been changed" (by whom, we don't > >> know or care). > >> > >> > >> > >> It's the best we've got so far. > >> > >> > >> > >> Aslak - do you have any thoughts as to the BDD-ness of this? It > >> seems to me that it's got a different structure from what we've > >> been recommending (i.e. context goes in setup - here context is > >> implied within specify), but it also seems very behaviour oriented > >> (BOP?????). > >> > >> > >> > >> Thoughts? > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Aslak Helles?y (aslak_hellesoy) > >> Date: 2006-11-15 17:10 > >> > >> Message: > >> I like that syntax! > >> > >> > >> > >> However, the last example might not work so well with Rails. > >> Consider this: > >> > >> > >> > >> @tim.should_change(:name).to("Larry") do > >> > >> post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} > >> > >> end > >> > >> > >> > >> It will probably update tim in the database, but it won't change > >> the @tim reference. You'll have to reload tim. Perhaps this would > >> work: > >> > >> > >> > >> @tim.should_change(:name).to("Larry") do > >> > >> post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} > >> > >> @tim.reload > >> > >> end > >> > >> > >> > >> Yeah, that should work I think. > >> > >> > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Brandon Keepers (brandon) > >> Date: 2006-11-15 16:56 > >> > >> Message: > >> What about this syntax: > >> > >> > >> > >> # non-deterministic > >> > >> User.should_change(:count) { ... } > >> > >> > >> > >> # increment/decrement > >> > >> User.should_change(:count).by(1) { ... } > >> > >> User.should_change(:count).by(-1) { ... } > >> > >> > >> > >> # verify that name changed and the new value should == "Larry" > >> > >> @tim.should_change(:name).to("Larry") { ... } > >> > >> # verify before and after > >> > >> @tim.should_change(:name).from("Tim").to("Larry") { ... } > >> > >> > >> > >> I haven't really thought about if the implementation of these > >> would work. I like that it doesn't use past tense and makes it > >> feel more like setting up the mock expectations instead of > >> verifying after-the-fact, which conceptually is more what this is > >> doing. > >> > >> > >> > >> Thoughts? > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: David Chelimsky (dchelimsky) > >> Date: 2006-11-15 11:53 > >> > >> Message: > >> I'd stay away from sugar. Sugar is only there to intercept > >> messages that start with "should_", hence the implementation. > >> > >> > >> > >> I do see the dilemma re: getting a handle on the User rather than > >> the value it returns for :count. Agreed that > >> User.should_return_different_results_for(:count).after { > >> > >> block here } is clunky, but I think that's the right direction. > >> Not sure of a better way to do it though. > >> > >> > >> > >> As for the plugin requiring a change for every release, that's > >> only temporary. We do plan to address plugins and extensions > >> because we want people to feel free to publish extensions. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Wilson Bilkovich (wilson) > >> Date: 2006-11-15 11:10 > >> > >> Message: > >> Oh, and Brandon's example: > >> > >> > >> > >> User.count.should_be_changed_by(1) { User.create(...) } > >> > >> > >> > >> ..is, as far as I can tell, impossible to implement without > >> > >> modifying the Ruby interpreter. > >> > >> If User.count starts out at 5, 'should' is being called on > >> > >> an instance of Fixnum. There's no way to tell what value to > >> > >> compare it to, after the block returns. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Wilson Bilkovich (wilson) > >> Date: 2006-11-15 11:08 > >> > >> Message: > >> That's precisely why I implemented it this way. I would much > >> > >> prefer to be able to write: > >> > >> User.count.should_be_changed..etc.etc.. > >> > >> ..but without a way to get a handle on the "method that was > >> > >> called to return the object that should was called on", I > >> > >> couldn't think of another way. > >> > >> > >> > >> Also, re: sugar.rb > >> > >> Here's a line of code from trunk: > >> > >> return original_method_missing.bind(self).call(sym, *args, > >> > >> &block) unless sym.to_s =~ /^should_/ > >> > >> As you can see, sugar assumes that the message being > >> > >> intercepted begins with 'should'. Because this patch > >> > >> requires a different behavior, I will still need to > >> > >> monkey-patch sugar.rb. > >> > >> > >> > >> I'm happy to do this as a plugin, it just looks like I would > >> > >> need to release a new version almost every time the trunk > >> > >> changed. > >> > >> > >> > >> The other way to implement this would be something like: > >> > >> User.should_return_different_results_for(:count).after { > >> > >> block here} > >> > >> > >> > >> ..but that seems clunky. I like the way this version reads, > >> > >> myself. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Brandon Keepers (brandon) > >> Date: 2006-11-15 09:26 > >> > >> Message: > >> Ok, looking into this a little, I see why it is implemented how it > >> is. The idea is that you want to check that the result of a > >> method call is changed by a block, not necessarily the referenced > >> object itself. It happens to work if the referenced object is > >> being modified, but what about when it's just being re-assigned? > >> > >> > >> > >> For example, this would work because :count is being incremented: > >> > >> > >> > >> User.count.should_be_changed_by(1) { User.create(...) } > >> > >> > >> > >> But, this would fail: > >> > >> > >> > >> @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } > >> > >> > >> > >> should_be_changed_to is looking that the referenced variable > >> changes, but in the block, I'm just reassigning it, so the > >> original reference to name is not modified. > >> > >> > >> > >> Thoughts? > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Brandon Keepers (brandon) > >> Date: 2006-11-15 09:06 > >> > >> Message: > >> So, the main issue is just the implementation, and not the feature > >> itself? I agree with you about it being too non-deterministic. > >> > >> > >> > >> I like the examples that you gave, it feels more like original the > >> assert_difference. > >> > >> > >> > >> I'd also like to see "should_be_changed_to(newval)" > >> > >> > >> > >> Maybe I'll get myself familiar with the rspec internals and > >> actually contribute instead of standing on the sidelines. ;) > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: David Chelimsky (dchelimsky) > >> Date: 2006-11-15 06:30 > >> > >> Message: > >> Brandon - re: inclusion as a core feature: > >> > >> > >> > >> I think it is too non-deterministic as/is. In the example, one > >> could override (accidentally, of course) User.create to delete > >> something and the spec would pass. > >> > >> > >> > >> We *could* make it more deterministic: > >> > >> > >> > >> User.count.should_be_changed_by('+ 1') do {...} > >> > >> > >> > >> or > >> > >> > >> > >> User.count.should_be_changed_from(3).to(4) do {...} > >> > >> > >> > >> One thing that concerns me is that we lose the separation between > >> context and outcome that is essential to BDD. > >> > >> > >> > >> Although it is very behavioral in nature. I'm on the fence. > >> > >> > >> > >> Thoughts? > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: David Chelimsky (dchelimsky) > >> Date: 2006-11-15 06:22 > >> > >> Message: > >> Wilson - re: your question about plugins and sugar: > >> > >> > >> > >> sugar.rb now only intercepts the :should_ part of > >> a :should_do_something message. What you want to extend is the > >> Should class itself (in this case with a 'changed_by' method that > >> takes a block), and the Not class if you want a negative counterpart. > >> > >> > >> > >> Be forewarned that we're not committing to the current structure > >> at this point, so you'd be incurring some risk that a future > >> version of RSpec might break your plugin because you're patching > >> something internal. We will, however, at some point soon (within a > >> month or two I think), publish (and thereby commit to) an entry > >> point to extending expectations. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Brandon Keepers (brandon) > >> Date: 2006-11-14 20:00 > >> > >> Message: > >> What is the reasoning for not including this as a core feature? > >> This is a very helpful expectation. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Aslak Helles?y (aslak_hellesoy) > >> Date: 2006-11-06 13:11 > >> > >> Message: > >> I don't think anyone has thought much about how a plugin mechanism > >> will actually be implemented. We'll try as hard as we can to make > >> something forward compatible and easy to use. > >> > >> > >> > >> Your patch here would be a good case to verify a plugin mechanism > >> against. > >> > >> > >> > >> I actually implemented this very feature a couple of months ago > >> (rel 0.5.14). We decided to remove the day after. The thread about > >> it starts here: > >> > >> > >> > >> http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html > >> > >> > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Wilson Bilkovich (wilson) > >> Date: 2006-11-06 12:51 > >> > >> Message: > >> Hrm. Are plugins going to be able to modify sugar.rb in a > >> > >> forward-compatible way? > >> > >> I'm not sure how to implement this without stepping in that > >> > >> early in the chain. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Comment By: Aslak Helles?y (aslak_hellesoy) > >> Date: 2006-11-06 12:45 > >> > >> Message: > >> I think this is the kind of stuff we'd encourage people to bundle > >> as an RSpec plugin. We don't have a plugin mechanism yet, but > >> we'll hopefully have one soon. > >> > >> --------------------------------------------------------------------- > >> - > >> > >> You can respond by visiting: > >> http://rubyforge.org/tracker/? > >> func=detail&atid=3151&aid=6417&group_id=797 > > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From noreply at rubyforge.org Thu Nov 16 11:58:47 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 11:58:47 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6608 ] RSpec 0.7.1 with ZenTest 3.4.2 raise TypeError on TestSession Message-ID: <20061116165847.53A85A970024@rubyforge.org> Bugs item #6608, was opened at 2006-11-10 15:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6608&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) >Assigned to: David Chelimsky (dchelimsky) Summary: RSpec 0.7.1 with ZenTest 3.4.2 raise TypeError on TestSession Initial Comment: ZenTest 3.4.2 defines TestSession is a Hash in their test_help.rb, althought Rails doesn't so neither pre-1.2 nor edge. I don't know why they've done that in 3.4.2 as I couldn't find ZenTest src repository... $ pwd /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails $ script/generate rspec exists spec identical spec/spec_helper.rb identical script/rails_spec identical script/rails_spec_server $ rake -q spec:app (in /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails) /Users/shintaro/gem.repos/gems/ZenTest-3.4.2/test/test_help.rb:5: superclass mismatch for class TestSession (TypeError) from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /Users/shintaro/gem.repos/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /Users/shintaro/gem.repos/gems/ZenTest-3.4.2/lib/test/rails.rb:2 from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `gem_original_require' from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `require' from /Users/shintaro/gem.repos/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /Users/shintaro/svn/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb:2 ... 11 levels... from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:21:in `run' from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:15:in `each' from /Users/shintaro/svn/rspec/trunk/lib/spec/runner/command_line.rb:15:in `run' from /Users/shintaro/svn/rspec/trunk/bin/spec:4 ... << snip (reoccurred in other 3 specs) >> ... rake aborted! RSpec failures (See full trace by running task with --trace) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 16:58 Message: The next release (0.7.3) does not depend on Zen ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-10 19:55 Message: Thanks, Shintaro for posting this: http://rubyforge.org/tracker/index.php?func=detail&aid=6610&group_id=419&atid=1678 This definitely looks like a ZenTest bug. Use ZenTest 3.4.1 until they fix it ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-10 19:10 Message: I ran into this as well. As a (scary) workaround, I inserted this before line 5 in test_help.rb: ActionController.send(:remove_const, :TestSession) ---------------------------------------------------------------------- Comment By: Shintaro Kakutani (kakutani) Date: 2006-11-10 16:04 Message: Is it a ZenTest's bug? --- test_help.rb.orig 2006-11-11 00:58:17.000000000 +0900 +++ test_help.rb 2006-11-11 00:58:33.000000000 +0900 @@ -1,8 +1,8 @@ # ActionPack module ActionController; end module ActionController::Flash; end -class ActionController::Flash::FlashHash; end -class ActionController::TestSession < Hash; end +class ActionController::Flash::FlashHash < Hash; end +class ActionController::TestSession; end class ActionController::TestRequest attr_accessor :session ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6608&group_id=797 From lists-rspec at shopwatch.org Thu Nov 16 13:28:26 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Thu, 16 Nov 2006 13:28:26 -0500 Subject: [rspec-devel] Mocking in the past tense In-Reply-To: <57c63afe0611092011s54ad4148t51c597f188b2c0d3@mail.gmail.com> References: <4553EEC5.7090403@shopwatch.org> <57c63afe0611092011s54ad4148t51c597f188b2c0d3@mail.gmail.com> Message-ID: <455CADCA.2000503@rubyforge.org> David Chelimsky wrote: > The idea of past-tense mocking has come up before. The problem is that > it only provides value in a very limited subset of potential uses. [...] > So, for me, I'd rather absorb the subtle dampness of the do_get method > and keep the specs clear. Good point - there's no way to post-specify what a mock should have returned! I guess the problem I have is in the disconnect between the English specification and the code. I'm finding specs that look like this: context "/controller/login" do setup do u = mock("User") u.stub!(:new).and_return(u) end specify "should redirect if login fails" do controller.should_redirect... u.should_receive(:login).and_return(false) post "login", :user => "louie", :password => "xxx" end specify "should render welcome if login succeeds" do controller.should_redirect.. u.should_receive(:login).and_return(true) post "login", ... end end What feels icky about this - whether I do mock_the_model in setup or in each spec - is that I never have a spec that explicitly outlines the "shoulds" that are specified as part of mocking. In controllers, especially, this seems to be the key part of the spec. In the spec above, there's only a single model verb that's mocked, but more complex controllers will obviously do more work. I find myself writing a bunch of "null specs" - that is, specs that do nothing but the mocking - to overcome that. But then I have to intentionally leave out some portion of the mock so that the mock corresponds with the English. It doesn't feel right, but I can't quite put my finger on what would feel better. Jay From bkeepers at gmail.com Thu Nov 16 14:28:09 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Thu, 16 Nov 2006 14:28:09 -0500 Subject: [rspec-devel] [PATCH] should_change In-Reply-To: <57c63afe0611160821y596a0ce3w5e884194944db2d0@mail.gmail.com> References: <20061116045428.9452152420AB@rubyforge.org> <57c63afe0611160821y596a0ce3w5e884194944db2d0@mail.gmail.com> Message-ID: <4F49D5DB-AB14-4EE6-8745-3D606F441DC6@gmail.com> Good suggestion. Here's an updated patch. Kudos to the Rspec team. You know this thing is architected right when making that kind of change takes two minutes (or less, if I knew how to type). Brandon -------------- next part -------------- A non-text attachment was scrubbed... Name: should_change.patch Type: application/octet-stream Size: 7210 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061116/b3241ca3/attachment.obj -------------- next part -------------- On Nov 16, 2006, at 11:21 AM, David Chelimsky wrote: > On first glance this looks great. I'll take a closer look tonight. > > The only thing I might do differently would be to add a Change class > (like Have) so the to, from, and by methods don't clutter up Should. > > Nice work! > > David > > On 11/16/06, Brandon Keepers wrote: >> I forgot to add support for chaining #to and #from. Here's an >> updated patch. Any thoughts? >> >> Brandon >> >> >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Thu Nov 16 15:55:10 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 15:55:10 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116205511.058D1A970016@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 15:55 Message: OK. How about this? (patch attached) I also added a sassy set of behavior when you invoke should_change on a symbol or string, instead of a proc. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 23:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 23:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 22:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 21:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From wilsonb at gmail.com Thu Nov 16 15:55:47 2006 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Thu, 16 Nov 2006 15:55:47 -0500 Subject: [rspec-devel] [PATCH] should_change In-Reply-To: <57c63afe0611160821y596a0ce3w5e884194944db2d0@mail.gmail.com> References: <20061116045428.9452152420AB@rubyforge.org> <57c63afe0611160821y596a0ce3w5e884194944db2d0@mail.gmail.com> Message-ID: Just submitted a fresh patch. I think it's pretty high-tech. I like it. On 11/16/06, David Chelimsky wrote: > On first glance this looks great. I'll take a closer look tonight. > > The only thing I might do differently would be to add a Change class > (like Have) so the to, from, and by methods don't clutter up Should. > > Nice work! > > David > > On 11/16/06, Brandon Keepers wrote: > > I forgot to add support for chaining #to and #from. Here's an > > updated patch. Any thoughts? > > > > Brandon > > > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Thu Nov 16 16:07:58 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 16:07:58 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116210758.54728A970027@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 16:07 Message: By the way.. despite the fact that I like the code in the new patch.. I still feel that the original syntax reads better. MUCH better, because I think lambdas are ugly. I am worried that we are trading off usability and readability here due to implementation issues. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 15:55 Message: OK. How about this? (patch attached) I also added a sassy set of behavior when you invoke should_change on a symbol or string, instead of a proc. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 23:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 23:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 22:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 21:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Thu Nov 16 16:18:41 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 16:18:41 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6578 ] Integrate SeleniumOnRails with rspec_selenium support Message-ID: <20061116211842.20872A970010@rubyforge.org> Feature Requests item #6578, was opened at 2006-11-08 18:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6578&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: Integrate SeleniumOnRails with rspec_selenium support Initial Comment: The idea of rspec's Selenium support is nice, but SeleniumOnRails provides some great features including the testrunner console, fixture loading, table clearing, etc. I don't know how feasible it is to integrate, since SOR uses Selenium-Core, and rspec currently uses Selenium-RC. But it's my feature request and so I get to ask for it. ---------------------------------------------------------------------- >Comment By: Jay Levitt (jaylev) Date: 2006-11-16 16:18 Message: There's no way to provide code for some of these, but I'll give you some stories instead. 1. Selenium on Rails provides a controller (added only in the test environment) that lets me: - load fixtures - clear specific tables - clear the session hash This is necessary because rspec's usual transactional fixtures can't work when rspec's running in a different process than the web server that the browser talks to. 2. SOR lets me see the progress of the test, and stops on the failed screen if a test fails. For some reason, even though the rest of rspec doesn't (can't) provide such a feature, I really missed this in the Selenium support; rspec closes the browser whether or not the test succeeds. 3. SOR provides a "test runner" control panel to control the speed of execution, let me run specific tests, etc. Perhaps a --walk option along with the new --line feature would suffice here. 4. SOR provides some nice Javascript magic that shows the test itself in a frame, and turns each step of the test green when it's executed. 5. I think the 'keep the browser open' patch should be integrated as a command-line or runtime option. These are listed in roughly the order I care about them; #1 and #2 especially are preventing me from switching from SOR to rspec's inbuilt support. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-13 13:41 Message: What kind of integration are you looking for? You have to be more specific. Code please. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6578&group_id=797 From noreply at rubyforge.org Thu Nov 16 16:35:11 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 16:35:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116213511.B1CDCA970004@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 16:35 Message: Good work on the patch. Very clean. One thought with using the Change class for negation. should_not_change now returns the Change class, which may lead people to believe they can do this: context "should_not_change.to" do specify "should pass when attribute is changed to something besides value" do lambda do lambda { @tim.name = "Steve" }.should_not_change(@tim, :name).to("Larry") end.should_pass end end My guess is that it is nearly impossible to implement that since you can't determine where to call the block. So this should probably be the case: context "should_not_change" do specify "should return nil" do lambda { }.should_not_change(@tim, :name).should_be_nil end end ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 16:07 Message: By the way.. despite the fact that I like the code in the new patch.. I still feel that the original syntax reads better. MUCH better, because I think lambdas are ugly. I am worried that we are trading off usability and readability here due to implementation issues. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 15:55 Message: OK. How about this? (patch attached) I also added a sassy set of behavior when you invoke should_change on a symbol or string, instead of a proc. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 23:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 23:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 22:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 21:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Thu Nov 16 16:48:19 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 16:48:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061116214819.CA886A970010@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 16:48 Message: Actually, that works. Maybe it needs a spec to prove it. Heh. lambda{}.should_not_change(@blah, :foo).to(x) doesn't make sense, because the initialize method of 'should not change' will already have failed the expectation by then. However, if you really wanted to be wordy, you actually could write: lambda{}.should_not_change(@blah, :foo).from(x) Unless I screwed something up, that will work. If the initial value wasn't x, it will fail. It will pass if the initial value was x, and the final value is also x. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 16:35 Message: Good work on the patch. Very clean. One thought with using the Change class for negation. should_not_change now returns the Change class, which may lead people to believe they can do this: context "should_not_change.to" do specify "should pass when attribute is changed to something besides value" do lambda do lambda { @tim.name = "Steve" }.should_not_change(@tim, :name).to("Larry") end.should_pass end end My guess is that it is nearly impossible to implement that since you can't determine where to call the block. So this should probably be the case: context "should_not_change" do specify "should return nil" do lambda { }.should_not_change(@tim, :name).should_be_nil end end ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 16:07 Message: By the way.. despite the fact that I like the code in the new patch.. I still feel that the original syntax reads better. MUCH better, because I think lambdas are ugly. I am worried that we are trading off usability and readability here due to implementation issues. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 15:55 Message: OK. How about this? (patch attached) I also added a sassy set of behavior when you invoke should_change on a symbol or string, instead of a proc. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 23:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 23:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 22:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 21:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Thu Nov 16 17:32:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 17:32:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6717 ] controller.should_render :partial not working Message-ID: <20061116223257.D2B0DA970010@rubyforge.org> Bugs item #6717, was opened at 2006-11-16 16:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6717&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Micah Martin (slagyr) Assigned to: Nobody (None) Summary: controller.should_render :partial not working Initial Comment: controller.should_render :partial => "view_widgets/_text_widget" Fails even when the controller does indeed render the partial. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6717&group_id=797 From noreply at rubyforge.org Thu Nov 16 18:09:34 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 18:09:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6717 ] controller.should_render :partial not working Message-ID: <20061116230934.82263A970010@rubyforge.org> Bugs item #6717, was opened at 2006-11-16 22:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6717&group_id=797 >Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Micah Martin (slagyr) >Assigned to: David Chelimsky (dchelimsky) Summary: controller.should_render :partial not working Initial Comment: controller.should_render :partial => "view_widgets/_text_widget" Fails even when the controller does indeed render the partial. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 23:09 Message: It should work without the underscore: controller.should_render :partial => "view_widgets/text_widget" I think that's how test/unit does it and how you code it in the controller. Do you think it's the wrong behavior? If so, what would be the right behavior? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6717&group_id=797 From lists-rspec at shopwatch.org Thu Nov 16 20:16:05 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Thu, 16 Nov 2006 20:16:05 -0500 Subject: [rspec-devel] Mocking in the past tense In-Reply-To: <455CADCA.2000503@rubyforge.org> References: <4553EEC5.7090403@shopwatch.org> <57c63afe0611092011s54ad4148t51c597f188b2c0d3@mail.gmail.com> <455CADCA.2000503@rubyforge.org> Message-ID: <455D0D55.3020202@rubyforge.org> Jay Levitt wrote: > David Chelimsky wrote: >> The idea of past-tense mocking has come up before. The problem is that >> it only provides value in a very limited subset of potential uses. > [...] >> So, for me, I'd rather absorb the subtle dampness of the do_get method >> and keep the specs clear. > > Good point - there's no way to post-specify what a mock should have > returned! More musing: I find myself mocking the same object over and over again, and having to explicitly specify "should_receives" for helper routines that I don't actually care about. What if a mock's behavior were specified independently of (and prior to) its expectations? Then I could, in a single place, specify: u = mock("User") u.may_receive(:get).and_return(users(:sample)) u.may_receive(:save).and_return(true) Later, for a given transaction, I might say: u.should_receive(:get).at_least(:once) I'd want to be able to override the returns, to test my error conditions: u.should_receive(:save).and_return(false) If may_receive is a synonym for stubs, and if a mock can override a stub today, then this may even work already. But I like the may_receive syntax, since I'm not really stubbing - I'm just building the framework for a mock. Jay From noreply at rubyforge.org Thu Nov 16 21:49:23 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 21:49:23 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061117024923.89A7EA970044@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 >Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) >Assigned to: David Chelimsky (dchelimsky) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 02:49 Message: Thank you so much for this patch! I applied it to trunk (rev 1115) with the following changes/exceptions: Added a couple of specs to get back to 100% coverage. Added expected messages to the specs. Refactored a few things for clarity (for me). Added a NotChange class. Did not include :symbol.should_change(receiver, :message). re: NotChange - that actually inspired me to add a NotHave class as well. Down w/ procedural conditionals! Up with polymorphic handling of conditionals! re: :symbol.should_change - I'm not really comfortable with that syntactically because it's difficult to know what the symbol is related to. If you feel strongly about the symbol syntax, please raise another RFE and we'll chat about it (I think the thread on this one is long enough already!) Cheers, David ps - working on docs now - will commit shortly ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 21:48 Message: Actually, that works. Maybe it needs a spec to prove it. Heh. lambda{}.should_not_change(@blah, :foo).to(x) doesn't make sense, because the initialize method of 'should not change' will already have failed the expectation by then. However, if you really wanted to be wordy, you actually could write: lambda{}.should_not_change(@blah, :foo).from(x) Unless I screwed something up, that will work. If the initial value wasn't x, it will fail. It will pass if the initial value was x, and the final value is also x. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 21:35 Message: Good work on the patch. Very clean. One thought with using the Change class for negation. should_not_change now returns the Change class, which may lead people to believe they can do this: context "should_not_change.to" do specify "should pass when attribute is changed to something besides value" do lambda do lambda { @tim.name = "Steve" }.should_not_change(@tim, :name).to("Larry") end.should_pass end end My guess is that it is nearly impossible to implement that since you can't determine where to call the block. So this should probably be the case: context "should_not_change" do specify "should return nil" do lambda { }.should_not_change(@tim, :name).should_be_nil end end ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 21:07 Message: By the way.. despite the fact that I like the code in the new patch.. I still feel that the original syntax reads better. MUCH better, because I think lambdas are ugly. I am worried that we are trading off usability and readability here due to implementation issues. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 20:55 Message: OK. How about this? (patch attached) I also added a sassy set of behavior when you invoke should_change on a symbol or string, instead of a proc. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 04:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 04:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 04:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 04:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 03:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 02:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 00:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 23:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 22:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 22:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 21:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 16:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Thu Nov 16 21:49:35 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 21:49:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061117024935.5BFEFA970042@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: expectation module Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: David Chelimsky (dchelimsky) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 02:49 Message: Thank you so much for this patch! I applied it to trunk (rev 1115) with the following changes/exceptions: Added a couple of specs to get back to 100% coverage. Added expected messages to the specs. Refactored a few things for clarity (for me). Added a NotChange class. Did not include :symbol.should_change(receiver, :message). re: NotChange - that actually inspired me to add a NotHave class as well. Down w/ procedural conditionals! Up with polymorphic handling of conditionals! re: :symbol.should_change - I'm not really comfortable with that syntactically because it's difficult to know what the symbol is related to. If you feel strongly about the symbol syntax, please raise another RFE and we'll chat about it (I think the thread on this one is long enough already!) Cheers, David ps - working on docs now - will commit shortly ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 21:48 Message: Actually, that works. Maybe it needs a spec to prove it. Heh. lambda{}.should_not_change(@blah, :foo).to(x) doesn't make sense, because the initialize method of 'should not change' will already have failed the expectation by then. However, if you really wanted to be wordy, you actually could write: lambda{}.should_not_change(@blah, :foo).from(x) Unless I screwed something up, that will work. If the initial value wasn't x, it will fail. It will pass if the initial value was x, and the final value is also x. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 21:35 Message: Good work on the patch. Very clean. One thought with using the Change class for negation. should_not_change now returns the Change class, which may lead people to believe they can do this: context "should_not_change.to" do specify "should pass when attribute is changed to something besides value" do lambda do lambda { @tim.name = "Steve" }.should_not_change(@tim, :name).to("Larry") end.should_pass end end My guess is that it is nearly impossible to implement that since you can't determine where to call the block. So this should probably be the case: context "should_not_change" do specify "should return nil" do lambda { }.should_not_change(@tim, :name).should_be_nil end end ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 21:07 Message: By the way.. despite the fact that I like the code in the new patch.. I still feel that the original syntax reads better. MUCH better, because I think lambdas are ugly. I am worried that we are trading off usability and readability here due to implementation issues. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 20:55 Message: OK. How about this? (patch attached) I also added a sassy set of behavior when you invoke should_change on a symbol or string, instead of a proc. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 04:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 04:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 04:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 04:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 03:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 02:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 00:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 23:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 22:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 22:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 21:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 16:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Thu Nov 16 23:15:41 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 23:15:41 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6707 ] cannot run controller / helper tests via rails_spec or spec only works with rake Message-ID: <20061117041541.9920DA970002@rubyforge.org> Bugs item #6707, was opened at 2006-11-16 14:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6707&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Nobody (None) >Assigned to: David Chelimsky (dchelimsky) Summary: cannot run controller / helper tests via rails_spec or spec only works with rake Initial Comment: I've tried four methods for running rails specs and here are the results for 0.7.2 (plugin and gem) on windows ruby spec/controllers/admin/some_controller_spec.rb - WORKS but not sure if supposed to do things this way? spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for (NoMethodError) Start rails_spec_server then ruby script\rails_spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for (NoMethodError) (SAME AS BEFORE) rake spec - WORKS FINE --- the sample test --- require File.dirname(__FILE__) + '/../../spec_helper' context "The Admin::TalentPoolsController" do # fixtures :talent_pools controller_name "admin/talent_pools" specify "should be a Admin::TalentPoolsController" do controller.should_be_an_instance_of Admin::TalentPoolsController end specify "should have more specifications" do violated "not enough specs" end end --- It seems that the module that contains the class method for controller_name does not get loaded except with rake / ruby? we really need the test suite not to reload each time (current rake takes 25 minutes or longer!) --- the same error happens with helpers and the call to helper_name ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 04:15 Message: Fixed in trunk (rev 1120). The problem was a path Regexp that failed to account for windows slashes. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6707&group_id=797 From noreply at rubyforge.org Thu Nov 16 23:17:27 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 23:17:27 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6071 ] script/rails_spec causes MissingSourceFile error Message-ID: <20061117041727.4A3E2A970002@rubyforge.org> Bugs item #6071, was opened at 2006-10-09 10:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6071&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: alan maybourne (nothingmuch) Assigned to: Nobody (None) Summary: script/rails_spec causes MissingSourceFile error Initial Comment: Windows XP Pro Ruby 1.8.4 Rails 1.1.6 rspec 0.6.4 I can successfully start the rspec server which gives the message "loading Rails Environment" followed by "Ready" but when I then try to use the rails_spec command here's what I get ----- C:\rails\morgan>ruby script/rails_spec reminder_spec.rb -f s c:/ruby/lib/ruby/1.8/drb/drb.rb:1090:in `method_missing': MissingSourceFile (DRb ::DRbUnknownError) from script/rails_spec:8 C:\rails\morgan> ----- running the spec on it's own using the spec command works fine ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 04:17 Message: Alan - is this still an issue for you (as of 0.7.2 or trunk 1120)? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6071&group_id=797 From noreply at rubyforge.org Thu Nov 16 23:23:07 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 23:23:07 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061117042307.4C7F8A970002@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: expectation module Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: David Chelimsky (dchelimsky) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 23:23 Message: Yeah. I like the polymorphic version better, for sure. Nice refactoring. The symbol thing came to me while I was getting coffee at Starbucks. I don't need it badly enough to fight for it. One tiny, tiny nitpick.. I used the: "blah blah #@instancevar" syntax, and you used "blah blah #{@instancevar}". The two are now mixed in change.rb. Should probably pick one and stick with it in the whole file. Good times. :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 21:49 Message: Thank you so much for this patch! I applied it to trunk (rev 1115) with the following changes/exceptions: Added a couple of specs to get back to 100% coverage. Added expected messages to the specs. Refactored a few things for clarity (for me). Added a NotChange class. Did not include :symbol.should_change(receiver, :message). re: NotChange - that actually inspired me to add a NotHave class as well. Down w/ procedural conditionals! Up with polymorphic handling of conditionals! re: :symbol.should_change - I'm not really comfortable with that syntactically because it's difficult to know what the symbol is related to. If you feel strongly about the symbol syntax, please raise another RFE and we'll chat about it (I think the thread on this one is long enough already!) Cheers, David ps - working on docs now - will commit shortly ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 16:48 Message: Actually, that works. Maybe it needs a spec to prove it. Heh. lambda{}.should_not_change(@blah, :foo).to(x) doesn't make sense, because the initialize method of 'should not change' will already have failed the expectation by then. However, if you really wanted to be wordy, you actually could write: lambda{}.should_not_change(@blah, :foo).from(x) Unless I screwed something up, that will work. If the initial value wasn't x, it will fail. It will pass if the initial value was x, and the final value is also x. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 16:35 Message: Good work on the patch. Very clean. One thought with using the Change class for negation. should_not_change now returns the Change class, which may lead people to believe they can do this: context "should_not_change.to" do specify "should pass when attribute is changed to something besides value" do lambda do lambda { @tim.name = "Steve" }.should_not_change(@tim, :name).to("Larry") end.should_pass end end My guess is that it is nearly impossible to implement that since you can't determine where to call the block. So this should probably be the case: context "should_not_change" do specify "should return nil" do lambda { }.should_not_change(@tim, :name).should_be_nil end end ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 16:07 Message: By the way.. despite the fact that I like the code in the new patch.. I still feel that the original syntax reads better. MUCH better, because I think lambdas are ugly. I am worried that we are trading off usability and readability here due to implementation issues. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 15:55 Message: OK. How about this? (patch attached) I also added a sassy set of behavior when you invoke should_change on a symbol or string, instead of a proc. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 23:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 23:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 22:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 21:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Thu Nov 16 23:35:46 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 23:35:46 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061117043546.496FFA970002@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: expectation module Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: David Chelimsky (dchelimsky) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 04:35 Message: Thanks Wilson. re: #@var vs #{@var}, the mixing and matching came from the patch :) :) :) Anyhow - do you have a preference for one over the other? I'll go either way. Thanks again for this - nice work - and nice collaborative effort. I really appreciate it. Cheers, David ps - OK - group hug - "kumbaya...." ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-17 04:23 Message: Yeah. I like the polymorphic version better, for sure. Nice refactoring. The symbol thing came to me while I was getting coffee at Starbucks. I don't need it badly enough to fight for it. One tiny, tiny nitpick.. I used the: "blah blah #@instancevar" syntax, and you used "blah blah #{@instancevar}". The two are now mixed in change.rb. Should probably pick one and stick with it in the whole file. Good times. :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 02:49 Message: Thank you so much for this patch! I applied it to trunk (rev 1115) with the following changes/exceptions: Added a couple of specs to get back to 100% coverage. Added expected messages to the specs. Refactored a few things for clarity (for me). Added a NotChange class. Did not include :symbol.should_change(receiver, :message). re: NotChange - that actually inspired me to add a NotHave class as well. Down w/ procedural conditionals! Up with polymorphic handling of conditionals! re: :symbol.should_change - I'm not really comfortable with that syntactically because it's difficult to know what the symbol is related to. If you feel strongly about the symbol syntax, please raise another RFE and we'll chat about it (I think the thread on this one is long enough already!) Cheers, David ps - working on docs now - will commit shortly ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 21:48 Message: Actually, that works. Maybe it needs a spec to prove it. Heh. lambda{}.should_not_change(@blah, :foo).to(x) doesn't make sense, because the initialize method of 'should not change' will already have failed the expectation by then. However, if you really wanted to be wordy, you actually could write: lambda{}.should_not_change(@blah, :foo).from(x) Unless I screwed something up, that will work. If the initial value wasn't x, it will fail. It will pass if the initial value was x, and the final value is also x. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 21:35 Message: Good work on the patch. Very clean. One thought with using the Change class for negation. should_not_change now returns the Change class, which may lead people to believe they can do this: context "should_not_change.to" do specify "should pass when attribute is changed to something besides value" do lambda do lambda { @tim.name = "Steve" }.should_not_change(@tim, :name).to("Larry") end.should_pass end end My guess is that it is nearly impossible to implement that since you can't determine where to call the block. So this should probably be the case: context "should_not_change" do specify "should return nil" do lambda { }.should_not_change(@tim, :name).should_be_nil end end ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 21:07 Message: By the way.. despite the fact that I like the code in the new patch.. I still feel that the original syntax reads better. MUCH better, because I think lambdas are ugly. I am worried that we are trading off usability and readability here due to implementation issues. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 20:55 Message: OK. How about this? (patch attached) I also added a sassy set of behavior when you invoke should_change on a symbol or string, instead of a proc. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 04:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 04:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 04:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 04:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 03:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 02:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 00:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 23:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 22:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 22:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 21:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 16:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Thu Nov 16 23:36:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 23:36:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061117043657.2C317A970002@rubyforge.org> Patches item #6417, was opened at 2006-10-31 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: expectation module Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: David Chelimsky (dchelimsky) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 04:36 Message: Brandon - thanks to you as well for playing along w/ this! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 04:35 Message: Thanks Wilson. re: #@var vs #{@var}, the mixing and matching came from the patch :) :) :) Anyhow - do you have a preference for one over the other? I'll go either way. Thanks again for this - nice work - and nice collaborative effort. I really appreciate it. Cheers, David ps - OK - group hug - "kumbaya...." ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-17 04:23 Message: Yeah. I like the polymorphic version better, for sure. Nice refactoring. The symbol thing came to me while I was getting coffee at Starbucks. I don't need it badly enough to fight for it. One tiny, tiny nitpick.. I used the: "blah blah #@instancevar" syntax, and you used "blah blah #{@instancevar}". The two are now mixed in change.rb. Should probably pick one and stick with it in the whole file. Good times. :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 02:49 Message: Thank you so much for this patch! I applied it to trunk (rev 1115) with the following changes/exceptions: Added a couple of specs to get back to 100% coverage. Added expected messages to the specs. Refactored a few things for clarity (for me). Added a NotChange class. Did not include :symbol.should_change(receiver, :message). re: NotChange - that actually inspired me to add a NotHave class as well. Down w/ procedural conditionals! Up with polymorphic handling of conditionals! re: :symbol.should_change - I'm not really comfortable with that syntactically because it's difficult to know what the symbol is related to. If you feel strongly about the symbol syntax, please raise another RFE and we'll chat about it (I think the thread on this one is long enough already!) Cheers, David ps - working on docs now - will commit shortly ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 21:48 Message: Actually, that works. Maybe it needs a spec to prove it. Heh. lambda{}.should_not_change(@blah, :foo).to(x) doesn't make sense, because the initialize method of 'should not change' will already have failed the expectation by then. However, if you really wanted to be wordy, you actually could write: lambda{}.should_not_change(@blah, :foo).from(x) Unless I screwed something up, that will work. If the initial value wasn't x, it will fail. It will pass if the initial value was x, and the final value is also x. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 21:35 Message: Good work on the patch. Very clean. One thought with using the Change class for negation. should_not_change now returns the Change class, which may lead people to believe they can do this: context "should_not_change.to" do specify "should pass when attribute is changed to something besides value" do lambda do lambda { @tim.name = "Steve" }.should_not_change(@tim, :name).to("Larry") end.should_pass end end My guess is that it is nearly impossible to implement that since you can't determine where to call the block. So this should probably be the case: context "should_not_change" do specify "should return nil" do lambda { }.should_not_change(@tim, :name).should_be_nil end end ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 21:07 Message: By the way.. despite the fact that I like the code in the new patch.. I still feel that the original syntax reads better. MUCH better, because I think lambdas are ugly. I am worried that we are trading off usability and readability here due to implementation issues. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 20:55 Message: OK. How about this? (patch attached) I also added a sassy set of behavior when you invoke should_change on a symbol or string, instead of a proc. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 04:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 04:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 04:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 04:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 03:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 02:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 00:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 00:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 00:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 23:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 22:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 22:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 21:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 16:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 16:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 14:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 01:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 18:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 17:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 17:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Thu Nov 16 23:39:20 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Nov 2006 23:39:20 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061117043921.08D84A970002@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: expectation module Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: David Chelimsky (dchelimsky) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 23:39 Message: #{@var} is probably easier for most people to read. I like #@var because it saves typing, and makes it easy to see that there are no method calls chained onto it. However, I use vim, and it has amazing syntax highlighting. It might be confusing for some other editors. Heh. #{@var} by a nose, I'd say. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 23:36 Message: Brandon - thanks to you as well for playing along w/ this! ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 23:35 Message: Thanks Wilson. re: #@var vs #{@var}, the mixing and matching came from the patch :) :) :) Anyhow - do you have a preference for one over the other? I'll go either way. Thanks again for this - nice work - and nice collaborative effort. I really appreciate it. Cheers, David ps - OK - group hug - "kumbaya...." ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 23:23 Message: Yeah. I like the polymorphic version better, for sure. Nice refactoring. The symbol thing came to me while I was getting coffee at Starbucks. I don't need it badly enough to fight for it. One tiny, tiny nitpick.. I used the: "blah blah #@instancevar" syntax, and you used "blah blah #{@instancevar}". The two are now mixed in change.rb. Should probably pick one and stick with it in the whole file. Good times. :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 21:49 Message: Thank you so much for this patch! I applied it to trunk (rev 1115) with the following changes/exceptions: Added a couple of specs to get back to 100% coverage. Added expected messages to the specs. Refactored a few things for clarity (for me). Added a NotChange class. Did not include :symbol.should_change(receiver, :message). re: NotChange - that actually inspired me to add a NotHave class as well. Down w/ procedural conditionals! Up with polymorphic handling of conditionals! re: :symbol.should_change - I'm not really comfortable with that syntactically because it's difficult to know what the symbol is related to. If you feel strongly about the symbol syntax, please raise another RFE and we'll chat about it (I think the thread on this one is long enough already!) Cheers, David ps - working on docs now - will commit shortly ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 16:48 Message: Actually, that works. Maybe it needs a spec to prove it. Heh. lambda{}.should_not_change(@blah, :foo).to(x) doesn't make sense, because the initialize method of 'should not change' will already have failed the expectation by then. However, if you really wanted to be wordy, you actually could write: lambda{}.should_not_change(@blah, :foo).from(x) Unless I screwed something up, that will work. If the initial value wasn't x, it will fail. It will pass if the initial value was x, and the final value is also x. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-16 16:35 Message: Good work on the patch. Very clean. One thought with using the Change class for negation. should_not_change now returns the Change class, which may lead people to believe they can do this: context "should_not_change.to" do specify "should pass when attribute is changed to something besides value" do lambda do lambda { @tim.name = "Steve" }.should_not_change(@tim, :name).to("Larry") end.should_pass end end My guess is that it is nearly impossible to implement that since you can't determine where to call the block. So this should probably be the case: context "should_not_change" do specify "should return nil" do lambda { }.should_not_change(@tim, :name).should_be_nil end end ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 16:07 Message: By the way.. despite the fact that I like the code in the new patch.. I still feel that the original syntax reads better. MUCH better, because I think lambdas are ugly. I am worried that we are trading off usability and readability here due to implementation issues. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-16 15:55 Message: OK. How about this? (patch attached) I also added a sassy set of behavior when you invoke should_change on a symbol or string, instead of a proc. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:54 Message: One piece of trickery I haven't managed to think my way through yet is.. If we want to support should_change().to("val") ..how can we support the bare should_change() call? If it needs to proxy for the 'to' and 'from' calls, how do we know there aren't more messages changed onto the end? The semi-equivalent 'Have' syntax seems to have avoided this by requiring a suffix method in every case. There's no: @thing.should_have(5) ..only @thing.should_have(5).things ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 23:46 Message: I agree with David. I actually really like this syntax. It feels very natural. lambda { ... }.should_change(obj, :method).to("val") ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 23:31 Message: Yeah, that and call_stack doesn't seem to work the way I'd expect: http://rpaste.com/pastes/575 I made some progress with set_trace_func, but oh lord is it slow. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 23:24 Message: I don't think the syntax is *much* nicer, but that's really a subjective thing :) I'd prefer the previous options because they align better w/ other constructs like should_raise and should_throw that we already use for blocks. I'd also like to avoid any dependencies unless they buy us a lot. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 22:57 Message: Hrm. Just saw this: http://eigenclass.org/hiki.rb?call_stack It is possible that I can use that to implement the much nicer syntax: User.count.should_be_changed.by {block} User.count.should_be_changed.from(x).to(y).by {block} How do we feel about a dependency on that, or something similar? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 21:12 Message: The proc will be @target, so just do this: @target.call Syntax? I like .to(x), .from(y) and .by(z) because it feels more like most of the rest of rspec. It'll also result in a more OO implementation. Consensus? Don't see one yet, but you have my recommendation. Cheers, David ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 19:36 Message: So, what is the consensus? specify "should take some discussion to get right" do proc{User.create :name => 'Bob'}.should_change(User, :count) proc{User.noop}.should_not_change(User, :count) end specify "should be fairly tricky" do proc{User.create :name => 'Bob'}.should_change(User, :count).by(1) end The 'by' version strikes me as a little domain-specific. It only works with values that support subtraction. Implementation-wise, how do I make the should proxy call the proc/lambda? Do we already have something like binding_of_caller in here? I also thing I slightly prefer the :to => and :from => version (an options Hash), though I will admit that that's partly because it is easier to implement. It avoids needing to subclass Should. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:28 Message: And, just so we don't forget: { ... }.should_not_change(@tim, :name) ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 19:25 Message: Good discussions! I'm really excited about this feature. I'm grasping at straws here because I don't know how the Rspec internals are implemented, but what if should_change(@tim, :name) actually called the proc and simply stored the before and after values, then #from, #to, and #by just called expectations on those references? Then, all forms would work regardless of order? # @before.should_not == @after { ... }.should_change(@tim, :name) # @before.should_not == @after # @after.should == "Larry" { ... }.should_change(@tim, :name).to("Larry") # @before.should_not == @after # @before.should == "Tim" # @after.should == "Larry" { ... }.should_change(@tim, :name).from("Tim").to("Larry") { ... }.should_change(@tim, :name).to("Larry").from("Tim") # @before.should_not == @after # @before.should == @after + -1 { ... }.should_change(User, :count).by(-1) Would that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:10 Message: Wilson - this was your baby originally. You want to resubmit a patch? Also, I'm on the fence re: syntax per my last comment. We *could* do this: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) If we call the proc on 'to' or 'by'. The nice thing about the other syntax is that it doesn't matter if you screw up the order: should_change(@time, :name, :to => 'Larry', :from => Tim); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); Those would behave the same way, whereas: should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :name).to('Larry').from('Tim') would not. It also supports simply: should_change(@time, :name) without any specifics. Less declarative, true, but it becomes the developers choice. Let us know if you want to submit a patch, and if you do if you want some direction. Otherwise we'll add this sometime soon. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 19:02 Message: I like the less verbose one, though that would be up to the developer. This aligns well w/ other expectations like: lambda {...}.should_raise lambda {...}.should_return (RFE 6187) I agree that we should add it now. And I think we should support the following forms: should_change(@tim, :name).to("Larry") should_change(@tim, :name).from('Tim').to('Larry') should_change(@tim, :age).by(1) Ah - but the middle one won't work because we won't know when to call the proc. How about this? should_change(@time, :name, :to => 'Larry'); should_change(@time, :name, :from => 'Tim', :to => 'Larry'); should_change(@time, :age, :by => 1); The reason I want from/to is to specify the value going in and coming out. I think that's more explicit. Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 18:48 Message: Right, it's not @tim changing his name, it's *something*. How about: lambda do ... end.should_change(@tim, :name).to("Larry") or slightly more readable (but more verbose): updating_tim = lambda do # do the post or whatever end updating_tim.should_change(@tim, :name).to("Larry") That's more aligned with the mocking syntax. I do think this is very much aligned with BDD. It provides a way to specify some general outcome (or observable behaviour) of an arbitrary chunk of code. I like it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 17:36 Message: This syntax is definitely better, though it's still a bit awkward in the sense that it reads like we're saying that @tim should be responsible for changing his name, as opposed to "after this action, @tim's name should have been changed" (by whom, we don't know or care). It's the best we've got so far. Aslak - do you have any thoughts as to the BDD-ness of this? It seems to me that it's got a different structure from what we've been recommending (i.e. context goes in setup - here context is implied within specify), but it also seems very behaviour oriented (BOP?????). Thoughts? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-15 17:10 Message: I like that syntax! However, the last example might not work so well with Rails. Consider this: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} end It will probably update tim in the database, but it won't change the @tim reference. You'll have to reload tim. Perhaps this would work: @tim.should_change(:name).to("Larry") do post 'update', {:id => @tim.id, :person => {:name => 'Larry'}} @tim.reload end Yeah, that should work I think. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 16:56 Message: What about this syntax: # non-deterministic User.should_change(:count) { ... } # increment/decrement User.should_change(:count).by(1) { ... } User.should_change(:count).by(-1) { ... } # verify that name changed and the new value should == "Larry" @tim.should_change(:name).to("Larry") { ... } # verify before and after @tim.should_change(:name).from("Tim").to("Larry") { ... } I haven't really thought about if the implementation of these would work. I like that it doesn't use past tense and makes it feel more like setting up the mock expectations instead of verifying after-the-fact, which conceptually is more what this is doing. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 11:53 Message: I'd stay away from sugar. Sugar is only there to intercept messages that start with "should_", hence the implementation. I do see the dilemma re: getting a handle on the User rather than the value it returns for :count. Agreed that User.should_return_different_results_for(:count).after { block here } is clunky, but I think that's the right direction. Not sure of a better way to do it though. As for the plugin requiring a change for every release, that's only temporary. We do plan to address plugins and extensions because we want people to feel free to publish extensions. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:10 Message: Oh, and Brandon's example: User.count.should_be_changed_by(1) { User.create(...) } ..is, as far as I can tell, impossible to implement without modifying the Ruby interpreter. If User.count starts out at 5, 'should' is being called on an instance of Fixnum. There's no way to tell what value to compare it to, after the block returns. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-15 11:08 Message: That's precisely why I implemented it this way. I would much prefer to be able to write: User.count.should_be_changed..etc.etc.. ..but without a way to get a handle on the "method that was called to return the object that should was called on", I couldn't think of another way. Also, re: sugar.rb Here's a line of code from trunk: return original_method_missing.bind(self).call(sym, *args, &block) unless sym.to_s =~ /^should_/ As you can see, sugar assumes that the message being intercepted begins with 'should'. Because this patch requires a different behavior, I will still need to monkey-patch sugar.rb. I'm happy to do this as a plugin, it just looks like I would need to release a new version almost every time the trunk changed. The other way to implement this would be something like: User.should_return_different_results_for(:count).after { block here} ..but that seems clunky. I like the way this version reads, myself. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:26 Message: Ok, looking into this a little, I see why it is implemented how it is. The idea is that you want to check that the result of a method call is changed by a block, not necessarily the referenced object itself. It happens to work if the referenced object is being modified, but what about when it's just being re-assigned? For example, this would work because :count is being incremented: User.count.should_be_changed_by(1) { User.create(...) } But, this would fail: @user.name.should_be_changed_to("Jim") { @user.name = "Jim" } should_be_changed_to is looking that the referenced variable changes, but in the block, I'm just reassigning it, so the original reference to name is not modified. Thoughts? ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-15 09:06 Message: So, the main issue is just the implementation, and not the feature itself? I agree with you about it being too non-deterministic. I like the examples that you gave, it feels more like original the assert_difference. I'd also like to see "should_be_changed_to(newval)" Maybe I'll get myself familiar with the rspec internals and actually contribute instead of standing on the sidelines. ;) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:30 Message: Brandon - re: inclusion as a core feature: I think it is too non-deterministic as/is. In the example, one could override (accidentally, of course) User.create to delete something and the spec would pass. We *could* make it more deterministic: User.count.should_be_changed_by('+ 1') do {...} or User.count.should_be_changed_from(3).to(4) do {...} One thing that concerns me is that we lose the separation between context and outcome that is essential to BDD. Although it is very behavioral in nature. I'm on the fence. Thoughts? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-15 06:22 Message: Wilson - re: your question about plugins and sugar: sugar.rb now only intercepts the :should_ part of a :should_do_something message. What you want to extend is the Should class itself (in this case with a 'changed_by' method that takes a block), and the Not class if you want a negative counterpart. Be forewarned that we're not committing to the current structure at this point, so you'd be incurring some risk that a future version of RSpec might break your plugin because you're patching something internal. We will, however, at some point soon (within a month or two I think), publish (and thereby commit to) an entry point to extending expectations. ---------------------------------------------------------------------- Comment By: Brandon Keepers (brandon) Date: 2006-11-14 20:00 Message: What is the reasoning for not including this as a core feature? This is a very helpful expectation. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 13:11 Message: I don't think anyone has thought much about how a plugin mechanism will actually be implemented. We'll try as hard as we can to make something forward compatible and easy to use. Your patch here would be a good case to verify a plugin mechanism against. I actually implemented this very feature a couple of months ago (rel 0.5.14). We decided to remove the day after. The thread about it starts here: http://rubyforge.org/pipermail/rspec-devel/2006-July/000324.html ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-06 12:51 Message: Hrm. Are plugins going to be able to modify sugar.rb in a forward-compatible way? I'm not sure how to implement this without stepping in that early in the chain. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-06 12:45 Message: I think this is the kind of stuff we'd encourage people to bundle as an RSpec plugin. We don't have a plugin mechanism yet, but we'll hopefully have one soon. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 From noreply at rubyforge.org Fri Nov 17 00:52:51 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 17 Nov 2006 00:52:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6720 ] [PATCH] ActiveRecord has_many :through and has_and_belongs_to_many break 'should' Message-ID: <20061117055251.407FD5240A85@rubyforge.org> Patches item #6720, was opened at 2006-11-17 00:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6720&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] ActiveRecord has_many :through and has_and_belongs_to_many break 'should' Initial Comment: Here's a stack trace (not mine, it's from aniero's app): TypeError in 'An instance of a Report model should set the condition relationships based on the condition string on save' wrong argument type Condition (expected Module) ../vendor/rails/activerecord/lib/active_record/base.rb:1235:in `method_missing' ../vendor/rails/activerecord/lib/active_record/associations/has_many_through_association.rb:110:in `method_missing' ../vendor/rails/activerecord/lib/active_record/base.rb:943:in `with_scope' ../vendor/rails/activerecord/lib/active_record/associations/has_many_through_association.rb:110:in `method_missing' ./spec/models/report_spec.rb:36 After some digging with bitsweat's assistance, it turns out that there are four different method_missing implementations in ActiveRecord that can be invoked when calling methods on associations. 1. AssociationProxy, for has_one and belongs_to 2. HasManyAssociation, for has_many 3. HasAndBelongsToManyAssociation, for habtm 4. HasManyThroughAssociation, for has_many through AssociationProxy's method_missing is pretty simple, and doesn't need wrapping. The others, however, make some decisions using respond_to?, etc, etc, and need RSpec to step in ahead of them. This patch adds the other two necessary. An example of where this currently fails is: @record.has_many_association.include? fixtures(:something) The 'rspec_on_rails' sample app doesn't include any habtm or hmt associations, so I couldn't write any specs to cover this. It might be worth adding those, so we can catch this kind of fun. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6720&group_id=797 From noreply at rubyforge.org Fri Nov 17 09:35:18 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 17 Nov 2006 09:35:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6720 ] [PATCH] ActiveRecord has_many :through and has_and_belongs_to_many break 'should' Message-ID: <20061117143518.D75C2A970002@rubyforge.org> Patches item #6720, was opened at 2006-11-17 05:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6720&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] ActiveRecord has_many :through and has_and_belongs_to_many break 'should' Initial Comment: Here's a stack trace (not mine, it's from aniero's app): TypeError in 'An instance of a Report model should set the condition relationships based on the condition string on save' wrong argument type Condition (expected Module) ../vendor/rails/activerecord/lib/active_record/base.rb:1235:in `method_missing' ../vendor/rails/activerecord/lib/active_record/associations/has_many_through_association.rb:110:in `method_missing' ../vendor/rails/activerecord/lib/active_record/base.rb:943:in `with_scope' ../vendor/rails/activerecord/lib/active_record/associations/has_many_through_association.rb:110:in `method_missing' ./spec/models/report_spec.rb:36 After some digging with bitsweat's assistance, it turns out that there are four different method_missing implementations in ActiveRecord that can be invoked when calling methods on associations. 1. AssociationProxy, for has_one and belongs_to 2. HasManyAssociation, for has_many 3. HasAndBelongsToManyAssociation, for habtm 4. HasManyThroughAssociation, for has_many through AssociationProxy's method_missing is pretty simple, and doesn't need wrapping. The others, however, make some decisions using respond_to?, etc, etc, and need RSpec to step in ahead of them. This patch adds the other two necessary. An example of where this currently fails is: @record.has_many_association.include? fixtures(:something) The 'rspec_on_rails' sample app doesn't include any habtm or hmt associations, so I couldn't write any specs to cover this. It might be worth adding those, so we can catch this kind of fun. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 14:35 Message: Would you like to patch the sample app so we have those specs? The sample app specs get run during the build, and serve as acceptance level tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6720&group_id=797 From noreply at rubyforge.org Fri Nov 17 10:07:03 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 17 Nov 2006 10:07:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6720 ] [PATCH] ActiveRecord has_many :through and has_and_belongs_to_many break 'should' Message-ID: <20061117150704.18471A970022@rubyforge.org> Patches item #6720, was opened at 2006-11-17 00:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6720&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] ActiveRecord has_many :through and has_and_belongs_to_many break 'should' Initial Comment: Here's a stack trace (not mine, it's from aniero's app): TypeError in 'An instance of a Report model should set the condition relationships based on the condition string on save' wrong argument type Condition (expected Module) ../vendor/rails/activerecord/lib/active_record/base.rb:1235:in `method_missing' ../vendor/rails/activerecord/lib/active_record/associations/has_many_through_association.rb:110:in `method_missing' ../vendor/rails/activerecord/lib/active_record/base.rb:943:in `with_scope' ../vendor/rails/activerecord/lib/active_record/associations/has_many_through_association.rb:110:in `method_missing' ./spec/models/report_spec.rb:36 After some digging with bitsweat's assistance, it turns out that there are four different method_missing implementations in ActiveRecord that can be invoked when calling methods on associations. 1. AssociationProxy, for has_one and belongs_to 2. HasManyAssociation, for has_many 3. HasAndBelongsToManyAssociation, for habtm 4. HasManyThroughAssociation, for has_many through AssociationProxy's method_missing is pretty simple, and doesn't need wrapping. The others, however, make some decisions using respond_to?, etc, etc, and need RSpec to step in ahead of them. This patch adds the other two necessary. An example of where this currently fails is: @record.has_many_association.include? fixtures(:something) The 'rspec_on_rails' sample app doesn't include any habtm or hmt associations, so I couldn't write any specs to cover this. It might be worth adding those, so we can catch this kind of fun. ---------------------------------------------------------------------- >Comment By: Wilson Bilkovich (wilson) Date: 2006-11-17 10:07 Message: OK. I will do that today. I guess it will need a couple of new models. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 09:35 Message: Would you like to patch the sample app so we have those specs? The sample app specs get run during the build, and serve as acceptance level tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6720&group_id=797 From noreply at rubyforge.org Fri Nov 17 11:37:33 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 17 Nov 2006 11:37:33 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6730 ] Unable to use fixtures in context Message-ID: <20061117163733.64235A970010@rubyforge.org> Bugs item #6730, was opened at 2006-11-17 10:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6730&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Yossef Mendelssohn (ymendel) Assigned to: Nobody (None) Summary: Unable to use fixtures in context Initial Comment: context "My Problem" do fixtures :my_problem end [ymendel]$ spec problem.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./problem.rb:2 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context.rb:14:in `initialize' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/extensions/kernel.rb:3:in `context' from ./problem.rb:1 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec:4 from /usr/local/bin/spec:18 I've seen a similar problem in bug 6411 (http://rubyforge.org/tracker/index.php?func=detail&aid=6411&group_id=797&atid=3149). The resolution there says it was fixed in r1088, and I'm using r1095 'gem list' returns rspec (0.7.2, 0.7.0) RSpec-0.7.2 (r1095) - BDD for Ruby http://rspec.rubyforge.org/ 'spec -v' returns RSpec-0.7.2 (r1095) - BDD for Ruby http://rspec.rubyforge.org/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6730&group_id=797 From noreply at rubyforge.org Fri Nov 17 12:28:19 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 17 Nov 2006 12:28:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6731 ] Partial templates rendered Message-ID: <20061117172819.24FC7A97001F@rubyforge.org> Feature Requests item #6731, was opened at 2006-11-17 12:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6731&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Partial templates rendered Initial Comment: Partial templates rendered in a view test. Such as
<%= render :partial => "widget_list" %>
I want to be able to test the content of this div as well as the content of the partial. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6731&group_id=797 From noreply at rubyforge.org Fri Nov 17 12:48:43 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 17 Nov 2006 12:48:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6730 ] Unable to use fixtures in context Message-ID: <20061117174843.1C40EA970010@rubyforge.org> Bugs item #6730, was opened at 2006-11-17 16:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6730&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Yossef Mendelssohn (ymendel) >Assigned to: David Chelimsky (dchelimsky) Summary: Unable to use fixtures in context Initial Comment: context "My Problem" do fixtures :my_problem end [ymendel]$ spec problem.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./problem.rb:2 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context.rb:14:in `initialize' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/extensions/kernel.rb:3:in `context' from ./problem.rb:1 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec:4 from /usr/local/bin/spec:18 I've seen a similar problem in bug 6411 (http://rubyforge.org/tracker/index.php?func=detail&aid=6411&group_id=797&atid=3149). The resolution there says it was fixed in r1088, and I'm using r1095 'gem list' returns rspec (0.7.2, 0.7.0) RSpec-0.7.2 (r1095) - BDD for Ruby http://rspec.rubyforge.org/ 'spec -v' returns RSpec-0.7.2 (r1095) - BDD for Ruby http://rspec.rubyforge.org/ ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 17:48 Message: The error points out that a Spec::Runner::ContextEvalModule is being invoked instead of a Spec::Rails::ModelContext, ::ControllerContext, ::HelperContext or ::ViewContext. The type of context is determined by the directory that the file is in. See http://rspec.rubyforge.org/documentation/rails/writing/index.html. If the path to the file is not in any of the paths listed on that page, the factory returns a Spec::Runner::ContextEvalModule by default. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6730&group_id=797 From noreply at rubyforge.org Fri Nov 17 21:33:02 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 17 Nov 2006 21:33:02 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6053 ] RSpec with Rails: skip_before_filter is ignored on edge rails Message-ID: <20061118023302.0915A5240BDB@rubyforge.org> Bugs item #6053, was opened at 2006-10-07 07:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6053&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: RSpec with Rails: skip_before_filter is ignored on edge rails Initial Comment: RSpec on Rails ignores skip_before_filter declarations in controllers being tested with RSpec. Appears to be non-issue with Rails 1.1.6. Broken on edge rails. Example code: # application.rb: class ApplicationController < ActionController::Base before_filter :raise_error def raise_error raise "This should never be called" end end # example_controller.rb class ExampleController < ApplicationController skip_before_filter :raise_error def tester render :text => 'hello world' end end # example_controller_spec.rb => raises error require File.dirname(__FILE__) + '/../spec_helper' context "The ExampleController" do controller_name :example specify "Should skip before_filter :raise_error" do get :tester response.should_be_success end end # example_controller_spec.rb => reports success require File.dirname(__FILE__) + '/../test_helper' require 'example_controller' # Re-raise errors caught by the controller. class ExampleController; def rescue_action(e) raise e end; end class ExampleControllerTest < Test::Unit::TestCase def setup @controller = ExampleController.new @request = ActionController::TestRequest.new @response = ActionController::TestResponse.new end # Replace this with your real tests. def test_no_error_without_rspec get :tester assert_response :success end end ---------------------------------------------------------------------- Comment By: Martin Emde (zraii) Date: 2006-11-17 19:33 Message: Some patches have added for this problem since this posting. Is it still a problem? If so, please post a bug on the rails trac. This is not likely RSpec's fault. ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-18 06:28 Message: I think this is related to http://dev.rubyonrails.org/ticket/5949 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6053&group_id=797 From noreply at rubyforge.org Sat Nov 18 00:52:43 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 18 Nov 2006 00:52:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6760 ] fatal error when accessing nested finders in rspec Message-ID: <20061118055243.8BE3A5240966@rubyforge.org> Bugs item #6760, was opened at 2006-11-18 00:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6760&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: fatal error when accessing nested finders in rspec Initial Comment: We have several models that have relationships defined like this (on edge rails): has_many :items do def incomplete find(:all, :conditions => 'completed_at is null') end def complete find(:all, :conditions => 'completed_at is not null') end end This let's you do things like object.items.incomplete and object.items.complete... however in rspec if you try to use a model that has this type of collection in 0.7.X and up you get a repeating error (2-3 pages of it) after a long delay (30-90 seconds) that says something along the lines of: [project_path]/config/../vendor/rails/activerecord/lib/active_record/associations/has_many_association.rb:98:in `method_missing' If you remove the nested finders (ie change it to just be has_many :items) it works fine again. I'll try to investigate and see if I can find the cause, submitting as bug as it's rather late here. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6760&group_id=797 From noreply at rubyforge.org Sat Nov 18 11:17:36 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 18 Nov 2006 11:17:36 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6760 ] fatal error when accessing nested finders in rspec Message-ID: <20061118161736.BA6CF5241269@rubyforge.org> Bugs item #6760, was opened at 2006-11-18 00:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6760&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) Assigned to: Nobody (None) Summary: fatal error when accessing nested finders in rspec Initial Comment: We have several models that have relationships defined like this (on edge rails): has_many :items do def incomplete find(:all, :conditions => 'completed_at is null') end def complete find(:all, :conditions => 'completed_at is not null') end end This let's you do things like object.items.incomplete and object.items.complete... however in rspec if you try to use a model that has this type of collection in 0.7.X and up you get a repeating error (2-3 pages of it) after a long delay (30-90 seconds) that says something along the lines of: [project_path]/config/../vendor/rails/activerecord/lib/active_record/associations/has_many_association.rb:98:in `method_missing' If you remove the nested finders (ie change it to just be has_many :items) it works fine again. I'll try to investigate and see if I can find the cause, submitting as bug as it's rather late here. ---------------------------------------------------------------------- >Comment By: Chad Humphries (spicycode) Date: 2006-11-18 11:17 Message: It looks like the line: ActiveRecord::Associations::HasManyAssociation.handle_underscores_for_rspec! is causing it. If I comment it out in the plugin (0.7.2) things start working again in tests against models with this type of association. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6760&group_id=797 From noreply at rubyforge.org Sun Nov 19 03:34:35 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 19 Nov 2006 03:34:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6053 ] RSpec with Rails: skip_before_filter is ignored on edge rails Message-ID: <20061119083435.D832B5240A51@rubyforge.org> Bugs item #6053, was opened at 2006-10-07 09:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6053&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: RSpec with Rails: skip_before_filter is ignored on edge rails Initial Comment: RSpec on Rails ignores skip_before_filter declarations in controllers being tested with RSpec. Appears to be non-issue with Rails 1.1.6. Broken on edge rails. Example code: # application.rb: class ApplicationController < ActionController::Base before_filter :raise_error def raise_error raise "This should never be called" end end # example_controller.rb class ExampleController < ApplicationController skip_before_filter :raise_error def tester render :text => 'hello world' end end # example_controller_spec.rb => raises error require File.dirname(__FILE__) + '/../spec_helper' context "The ExampleController" do controller_name :example specify "Should skip before_filter :raise_error" do get :tester response.should_be_success end end # example_controller_spec.rb => reports success require File.dirname(__FILE__) + '/../test_helper' require 'example_controller' # Re-raise errors caught by the controller. class ExampleController; def rescue_action(e) raise e end; end class ExampleControllerTest < Test::Unit::TestCase def setup @controller = ExampleController.new @request = ActionController::TestRequest.new @response = ActionController::TestResponse.new end # Replace this with your real tests. def test_no_error_without_rspec get :tester assert_response :success end end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-19 03:34 Message: I cannot reproduce this. Closing it for now. ---------------------------------------------------------------------- Comment By: Martin Emde (zraii) Date: 2006-11-17 21:33 Message: Some patches have added for this problem since this posting. Is it still a problem? If so, please post a bug on the rails trac. This is not likely RSpec's fault. ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-18 08:28 Message: I think this is related to http://dev.rubyonrails.org/ticket/5949 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6053&group_id=797 From noreply at rubyforge.org Sun Nov 19 03:35:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 19 Nov 2006 03:35:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6053 ] RSpec with Rails: skip_before_filter is ignored on edge rails Message-ID: <20061119083557.A24995240A51@rubyforge.org> Bugs item #6053, was opened at 2006-10-07 09:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6053&group_id=797 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Nobody (None) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec with Rails: skip_before_filter is ignored on edge rails Initial Comment: RSpec on Rails ignores skip_before_filter declarations in controllers being tested with RSpec. Appears to be non-issue with Rails 1.1.6. Broken on edge rails. Example code: # application.rb: class ApplicationController < ActionController::Base before_filter :raise_error def raise_error raise "This should never be called" end end # example_controller.rb class ExampleController < ApplicationController skip_before_filter :raise_error def tester render :text => 'hello world' end end # example_controller_spec.rb => raises error require File.dirname(__FILE__) + '/../spec_helper' context "The ExampleController" do controller_name :example specify "Should skip before_filter :raise_error" do get :tester response.should_be_success end end # example_controller_spec.rb => reports success require File.dirname(__FILE__) + '/../test_helper' require 'example_controller' # Re-raise errors caught by the controller. class ExampleController; def rescue_action(e) raise e end; end class ExampleControllerTest < Test::Unit::TestCase def setup @controller = ExampleController.new @request = ActionController::TestRequest.new @response = ActionController::TestResponse.new end # Replace this with your real tests. def test_no_error_without_rspec get :tester assert_response :success end end ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-19 03:34 Message: I cannot reproduce this. Closing it for now. ---------------------------------------------------------------------- Comment By: Martin Emde (zraii) Date: 2006-11-17 21:33 Message: Some patches have added for this problem since this posting. Is it still a problem? If so, please post a bug on the rails trac. This is not likely RSpec's fault. ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-18 08:28 Message: I think this is related to http://dev.rubyonrails.org/ticket/5949 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6053&group_id=797 From dchelimsky at gmail.com Sun Nov 19 08:29:48 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 19 Nov 2006 07:29:48 -0600 Subject: [rspec-devel] artificial sugar causes cancer Message-ID: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com> All, If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 you'll see that Chad (the submitter) found the source of the bug. Unfortunately, the source of *this* bug is the *solution* to a *previous bug* in which Rails was replacing RSpec's method missing with its own. When we settled on underscores, my one reservation was that we'd keep running into this particular problem - RSpec's method_missing conflicting with others. I have a proposition that preserves the underscore syntax, makes some examples even more clear, and eliminates this problem once and for all. 1. Eliminate reliance on method missing to handle expectations by adding all of the documented should_x_y_z methods directly to Object. These would all delegate off to Spec::Expectations::Should, ::Not, ::Have, etc, so the design wouldn't change much and Object itself, though bloated w/ methods, would not be bloated w/ implementation. This would also give us a single expectations module that we add to Object, providing several benefits including: # more clarity in the API # a place to put meaningful rdoc # a potential formal plugin point 2. Change should_be to ONLY handle arbitrary predicates (not serve as an alias for should_equal): subject.should_be :empty => passes if subject.empty? subject.should_be :instance_of, SomeClass => passes if subject.instance_of? SomeClass etc... In my opinion (feel free to disagree), this actually makes these examples more readable. Consider these two: @bdd_framework.should_be_adopted_quickly #current @bdd_framework.should_be :adopted_quickly #proposed In my view, these read equally well from a language perspective AND they make it easier for a developer to mentally separate the expectation (should_be) from the expected value (adopted_quickly?). This WOULD require changes to existing specs. I think for those of you who don't wrap expectation args in parens that a trivial script would handle this for you. If you do use parens, the script might be more complex. Perhaps if we *do* choose this direction, one of you would like to contribute such a script. I fully recognize that this would cause some pain, but it is my feeling that not addressing this leaves us in a crippled position in which we commit to being sidetracked by this issue constantly returning instead of focusing on enhancing the API. I also think that this is a better option than any of the following that also crossed my mind: * revert to dots * figure out a sexy way to intercept all attempts to rewrite method missing and re-inject RSpec's method missing in its place (perhaps this does sound sexy, but I doth believe that there is a venereal disease hiding in its midst) * leave things as they are and continue to add ugly hacks like NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get so call it that) * hang myself from the nearest bridge Of course, if you have any solutions to propose, I'm all eyes. Thoughts? Thanks, David From noreply at rubyforge.org Sun Nov 19 09:49:46 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 19 Nov 2006 09:49:46 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6780 ] routing() was failing...fix included Message-ID: <20061119144946.5E64252411C1@rubyforge.org> Bugs item #6780, was opened at 2006-11-19 16:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Gustav Paul (gustavpaul) Assigned to: Nobody (None) Summary: routing() was failing...fix included Initial Comment: Hey I have the following route in my config/routes.rb: map.connect 'login', :controller => 'member', :action => 'login' my spec looks as follows #no def setup or anything similar... specify "/member/login should route to /login" do routing(:controller => 'member', :action => 'login').should_eql "/login" end Was failing, reporting inequality of 47 and '/login' "/login"[0] happened to be char code 47 I've got the rails plugin installed as /vendor/plugins/rspec_on_rails In /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb line #131 Was: ActionController::Routing::Routes.generate(options)[0] changed to ActionController::Routing::Routes.generate(options) Working perfectly now... Might have introduced other bugs, but I though I'd let you guys know... Cheery-o Gustav Paul gustav at rails.co.za ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 From noreply at rubyforge.org Sun Nov 19 10:26:09 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 19 Nov 2006 10:26:09 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6713 ] helper methods not rendered in view tests? Message-ID: <20061119152609.ED05C52411FB@rubyforge.org> Feature Requests item #6713, was opened at 2006-11-16 17:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6713&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Micah Martin (slagyr) Assigned to: Nobody (None) Summary: helper methods not rendered in view tests? Initial Comment: Apprently helpers are not rendered in view tests... template _xyz:
<% form_remote_tag :update => "some_div", :url => {:action => :something } %> <% end_form_tag %>
failing spec: specify "Form is rendered" do render "/controller/_xyz" response.should_have_tag 'form', :parent => { :tag => "div" } end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-19 15:26 Message: moving this to Bugs ---------------------------------------------------------------------- Comment By: Micah Martin (slagyr) Date: 2006-11-17 17:31 Message: The above example has a mistake... the form_remote_tag tag is missing an =. Still, custom helper methods are not being resolved in view specs. For example if I have in app/helpers/controller_helper.rb: def my_helper return "blah" end And in my template I use: <%= my_helper %> The view tests will throw an error: undefined method `my_helper' for #<#:0x2691a80> ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6713&group_id=797 From noreply at rubyforge.org Sun Nov 19 10:26:49 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 19 Nov 2006 10:26:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6713 ] helper methods not rendered in view tests? Message-ID: <20061119152649.4CD6552411F7@rubyforge.org> Bugs item #6713, was opened at 2006-11-16 17:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6713&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Micah Martin (slagyr) Assigned to: Nobody (None) Summary: helper methods not rendered in view tests? Initial Comment: Apprently helpers are not rendered in view tests... template _xyz:
<% form_remote_tag :update => "some_div", :url => {:action => :something } %> <% end_form_tag %>
failing spec: specify "Form is rendered" do render "/controller/_xyz" response.should_have_tag 'form', :parent => { :tag => "div" } end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-19 15:26 Message: moving this to Bugs ---------------------------------------------------------------------- Comment By: Micah Martin (slagyr) Date: 2006-11-17 17:31 Message: The above example has a mistake... the form_remote_tag tag is missing an =. Still, custom helper methods are not being resolved in view specs. For example if I have in app/helpers/controller_helper.rb: def my_helper return "blah" end And in my template I use: <%= my_helper %> The view tests will throw an error: undefined method `my_helper' for #<#:0x2691a80> ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6713&group_id=797 From noreply at rubyforge.org Sun Nov 19 10:29:21 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 19 Nov 2006 10:29:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6713 ] helper methods not rendered in view tests? Message-ID: <20061119152921.B633F52411E8@rubyforge.org> Bugs item #6713, was opened at 2006-11-16 17:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6713&group_id=797 >Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Micah Martin (slagyr) >Assigned to: David Chelimsky (dchelimsky) Summary: helper methods not rendered in view tests? Initial Comment: Apprently helpers are not rendered in view tests... template _xyz:
<% form_remote_tag :update => "some_div", :url => {:action => :something } %> <% end_form_tag %>
failing spec: specify "Form is rendered" do render "/controller/_xyz" response.should_have_tag 'form', :parent => { :tag => "div" } end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-19 15:29 Message: Fixed in trunk (rev 1123). Docs coming soon.... Basically: the view spec does the following: 1. tries to include an implicit helper. For example: render 'person/show' would try to include PersonHelper 2. includes any specified helper render 'person/show', :helper => 'AddressHelper' render 'person/show', :helpers => ['AddressHelper','ZipCodeHelper'] ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-19 15:26 Message: moving this to Bugs ---------------------------------------------------------------------- Comment By: Micah Martin (slagyr) Date: 2006-11-17 17:31 Message: The above example has a mistake... the form_remote_tag tag is missing an =. Still, custom helper methods are not being resolved in view specs. For example if I have in app/helpers/controller_helper.rb: def my_helper return "blah" end And in my template I use: <%= my_helper %> The view tests will throw an error: undefined method `my_helper' for #<#:0x2691a80> ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6713&group_id=797 From noreply at rubyforge.org Sun Nov 19 15:31:03 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 19 Nov 2006 15:31:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6674 ] rspec_on_rails fails on @session deprecation warning? Message-ID: <20061119203103.A4DC55240B77@rubyforge.org> Bugs item #6674, was opened at 2006-11-14 18:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6674&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Steve Ross (sxross) Assigned to: Nobody (None) Summary: rspec_on_rails fails on @session deprecation warning? Initial Comment: rSpec 0.7.2 and rspec_on_rails 0.7.2 on Edge Rails (5473). I'm not certain that the deprecation warnings are causing this, but that's how it looks to me. By the way, the line 'puts self.class' outputs 'F'. Is this expected? Simple view test: require File.dirname(__FILE__) + '/../spec_helper' context "/member/index" do setup do @member = mock("member") @content_for_title = 'sign up for mailing list' @member.should_receive(:member) assigns[:member] = [@member] end specify "should show signup page" do puts self.class render '/member/index' response.should_have_tag 'div', attributes =>{:id => "intro"} end end Results: 1) RuntimeError in '/member/index should show signup page' Deprecating @session, but it's already set to #{}}>! Use the session= writer method instead of setting @session directly. /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1049:in `assign_deprecated_shortcuts' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1044:in `assign_deprecated_shortcuts' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1035:in `assign_shortcuts_without_flash' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/flash.rb:140:in `assign_shortcuts' Finished in 0.063727 seconds 1 specification, 1 failure rake aborted! Command failed with status (1): [/usr/local/bin/ruby -I"/usr/local/lib/ruby...] ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-19 20:30 Message: Moving this to bugs ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6674&group_id=797 From dchelimsky at gmail.com Sun Nov 19 16:34:35 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 19 Nov 2006 15:34:35 -0600 Subject: [rspec-devel] underscores, sugar, and more and more bugs Message-ID: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> I sent this earlier under with the subject "artificial sugar causes cancer" and I think some spam filters ate it. Here it is again: ====================================== All, If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 you'll see that Chad (the submitter) found the source of the bug. Unfortunately, the source of *this* bug is the *solution* to a *previous bug* in which Rails was replacing RSpec's method missing with its own. When we settled on underscores, my one reservation was that we'd keep running into this particular problem - RSpec's method_missing conflicting with others. I have a proposition that preserves the underscore syntax, makes some examples even more clear, and eliminates this problem once and for all. 1. Eliminate reliance on method missing to handle expectations by adding all of the documented should_x_y_z methods directly to Object. These would all delegate off to Spec::Expectations::Should, ::Not, ::Have, etc, so the design wouldn't change much and Object itself, though bloated w/ methods, would not be bloated w/ implementation. This would also give us a single expectations module that we add to Object, providing several benefits including: # more clarity in the API # a place to put meaningful rdoc # a potential formal plugin point 2. Change should_be to ONLY handle arbitrary predicates (not serve as an alias for should_equal): subject.should_be :empty => passes if subject.empty? subject.should_be :instance_of, SomeClass => passes if subject.instance_of? SomeClass etc... In my opinion (feel free to disagree), this actually makes these examples more readable. Consider these two: @bdd_framework.should_be_adopted_quickly #current @bdd_framework.should_be :adopted_quickly #proposed In my view, these read equally well from a language perspective AND they make it easier for a developer to mentally separate the expectation (should_be) from the expected value (adopted_quickly?). This WOULD require changes to existing specs. I think for those of you who don't wrap expectation args in parens that a trivial script would handle this for you. If you do use parens, the script might be more complex. Perhaps if we *do* choose this direction, one of you would like to contribute such a script. I fully recognize that this would cause some pain, but it is my feeling that not addressing this leaves us in a crippled position in which we commit to being sidetracked by this issue constantly returning instead of focusing on enhancing the API. I also think that this is a better option than any of the following that also crossed my mind: * revert to dots * figure out a sexy way to intercept all attempts to rewrite method missing and re-inject RSpec's method missing in its place (perhaps this does sound sexy, but I doth believe that there is a venereal disease hiding in its midst) * leave things as they are and continue to add ugly hacks like NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get so call it that) * hang myself from the nearest bridge Of course, if you have any solutions to propose, I'm all eyes. Thoughts? Thanks, David From noreply at rubyforge.org Sun Nov 19 17:47:53 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 19 Nov 2006 17:47:53 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6731 ] Partial templates rendered Message-ID: <20061119224753.5D0F95240EB9@rubyforge.org> Feature Requests item #6731, was opened at 2006-11-17 17:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6731&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: Nobody (None) >Assigned to: David Chelimsky (dchelimsky) Summary: Partial templates rendered Initial Comment: Partial templates rendered in a view test. Such as
<%= render :partial => "widget_list" %>
I want to be able to test the content of this div as well as the content of the partial. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-19 22:47 Message: Of course, you mean 'spec the content....' When I tried this it just worked, so it must have been fixed by some other change that's happened. In trunk (rev 1124). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6731&group_id=797 From noreply at rubyforge.org Sun Nov 19 20:11:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 19 Nov 2006 20:11:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6717 ] controller.should_render :partial not working Message-ID: <20061120011150.7F4D2524104D@rubyforge.org> Bugs item #6717, was opened at 2006-11-16 22:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6717&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Micah Martin (slagyr) Assigned to: David Chelimsky (dchelimsky) Summary: controller.should_render :partial not working Initial Comment: controller.should_render :partial => "view_widgets/_text_widget" Fails even when the controller does indeed render the partial. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-20 01:11 Message: OK - I looked into this and there were some other problems with this. It now works correctly in integration or isolation mode, however you have to use "view_widgets/text_widget", not "view_widgets/_text_widget". Fixed in trunk (rev 1125) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-16 23:09 Message: It should work without the underscore: controller.should_render :partial => "view_widgets/text_widget" I think that's how test/unit does it and how you code it in the controller. Do you think it's the wrong behavior? If so, what would be the right behavior? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6717&group_id=797 From noreply at rubyforge.org Sun Nov 19 22:36:30 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 19 Nov 2006 22:36:30 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6780 ] routing() was failing...fix included Message-ID: <20061120033630.EF1E752415C9@rubyforge.org> Bugs item #6780, was opened at 2006-11-19 14:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Gustav Paul (gustavpaul) >Assigned to: David Chelimsky (dchelimsky) Summary: routing() was failing...fix included Initial Comment: Hey I have the following route in my config/routes.rb: map.connect 'login', :controller => 'member', :action => 'login' my spec looks as follows #no def setup or anything similar... specify "/member/login should route to /login" do routing(:controller => 'member', :action => 'login').should_eql "/login" end Was failing, reporting inequality of 47 and '/login' "/login"[0] happened to be char code 47 I've got the rails plugin installed as /vendor/plugins/rspec_on_rails In /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb line #131 Was: ActionController::Routing::Routes.generate(options)[0] changed to ActionController::Routing::Routes.generate(options) Working perfectly now... Might have introduced other bugs, but I though I'd let you guys know... Cheery-o Gustav Paul gustav at rails.co.za ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-20 03:36 Message: Gustav - I added a spec for this and it passed right away. It's committed in revision (1126). What version of RSpec were you using when this happened? Trunk revision? Rails version? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 From dchelimsky at gmail.com Sun Nov 19 23:19:12 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 19 Nov 2006 22:19:12 -0600 Subject: [rspec-devel] Mocking in the past tense In-Reply-To: <455D0D55.3020202@rubyforge.org> References: <4553EEC5.7090403@shopwatch.org> <57c63afe0611092011s54ad4148t51c597f188b2c0d3@mail.gmail.com> <455CADCA.2000503@rubyforge.org> <455D0D55.3020202@rubyforge.org> Message-ID: <57c63afe0611192019x33ef48bcvd7d7f4c645edcdd9@mail.gmail.com> On 11/16/06, Jay Levitt wrote: > Jay Levitt wrote: > > David Chelimsky wrote: > >> The idea of past-tense mocking has come up before. The problem is that > >> it only provides value in a very limited subset of potential uses. > > [...] > >> So, for me, I'd rather absorb the subtle dampness of the do_get method > >> and keep the specs clear. > > > > Good point - there's no way to post-specify what a mock should have > > returned! > > More musing: I find myself mocking the same object over and over again, > and having to explicitly specify "should_receives" for helper routines > that I don't actually care about. > > What if a mock's behavior were specified independently of (and prior to) > its expectations? > > Then I could, in a single place, specify: > > u = mock("User") > u.may_receive(:get).and_return(users(:sample)) > u.may_receive(:save).and_return(true) > > Later, for a given transaction, I might say: > > u.should_receive(:get).at_least(:once) > > I'd want to be able to override the returns, to test my error conditions: > > u.should_receive(:save).and_return(false) > > If may_receive is a synonym for stubs, and if a mock can override a stub > today, then this may even work already. It does. Check out http://blog.davidchelimsky.net/articles/2006/11/09/tutorial-rspec-stubs-and-mocks > But I like the may_receive > syntax, since I'm not really stubbing - I'm just building the framework > for a mock. I think that depends on what your view of a stub is. To me, it's the same as what you're describing as may_receive. Read the blog and let me know what you think? > > Jay > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From lists-rspec at shopwatch.org Mon Nov 20 07:34:42 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Mon, 20 Nov 2006 07:34:42 -0500 Subject: [rspec-devel] Mocking in the past tense In-Reply-To: <57c63afe0611192019x33ef48bcvd7d7f4c645edcdd9@mail.gmail.com> References: <4553EEC5.7090403@shopwatch.org> <57c63afe0611092011s54ad4148t51c597f188b2c0d3@mail.gmail.com> <455CADCA.2000503@rubyforge.org> <455D0D55.3020202@rubyforge.org> <57c63afe0611192019x33ef48bcvd7d7f4c645edcdd9@mail.gmail.com> Message-ID: <4561A0E2.1030509@rubyforge.org> David Chelimsky wrote: >> >> If may_receive is a synonym for stubs, and if a mock can override a stub >> today, then this may even work already. > > It does. Check out > http://blog.davidchelimsky.net/articles/2006/11/09/tutorial-rspec-stubs-and-mocks > >> But I like the may_receive >> syntax, since I'm not really stubbing - I'm just building the framework >> for a mock. > > I think that depends on what your view of a stub is. To me, it's the > same as what you're describing as may_receive. Read the blog and let > me know what you think? You're right. I was thinking of stubs and mocks as independent objects. But what we're really doing here is stubbing most of an object and mocking part of it, and so the current syntax is actually quite descriptive. Thanks for the blog example; that really clarified things for me, and it oughta make its way into the doc somehow. Jay > >> Jay >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Mon Nov 20 09:02:10 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 20 Nov 2006 09:02:10 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6730 ] Unable to use fixtures in context Message-ID: <20061120140210.38DFC52417FA@rubyforge.org> Bugs item #6730, was opened at 2006-11-17 10:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6730&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Yossef Mendelssohn (ymendel) Assigned to: David Chelimsky (dchelimsky) Summary: Unable to use fixtures in context Initial Comment: context "My Problem" do fixtures :my_problem end [ymendel]$ spec problem.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./problem.rb:2 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context.rb:14:in `initialize' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/extensions/kernel.rb:3:in `context' from ./problem.rb:1 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec:4 from /usr/local/bin/spec:18 I've seen a similar problem in bug 6411 (http://rubyforge.org/tracker/index.php?func=detail&aid=6411&group_id=797&atid=3149). The resolution there says it was fixed in r1088, and I'm using r1095 'gem list' returns rspec (0.7.2, 0.7.0) RSpec-0.7.2 (r1095) - BDD for Ruby http://rspec.rubyforge.org/ 'spec -v' returns RSpec-0.7.2 (r1095) - BDD for Ruby http://rspec.rubyforge.org/ ---------------------------------------------------------------------- >Comment By: Yossef Mendelssohn (ymendel) Date: 2006-11-20 08:02 Message: Ah, so it's not determining the context. However, my problem still exists if I try a spec in the models directory. Could it be that I'm using Engines and not plain vanilla Rails? I have my own spec_helper.rb that includes the line self.fixture_path = RAILS_ROOT + '/vendor/plugins/base/spec/fixtures' (instead of RAILS_ROOT + '/spec/fixtures') but maybe I need something to also point out the different path for the specs? Also, the paths listed on that page are a little confusing. Given that I'm in a 'spec' directory, the path should match '../spec/models/**/*_spec.rb', yes? If that's the case, the problem spec matches. irb confirms that. If there's something more, then I don't know. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 11:48 Message: The error points out that a Spec::Runner::ContextEvalModule is being invoked instead of a Spec::Rails::ModelContext, ::ControllerContext, ::HelperContext or ::ViewContext. The type of context is determined by the directory that the file is in. See http://rspec.rubyforge.org/documentation/rails/writing/index.html. If the path to the file is not in any of the paths listed on that page, the factory returns a Spec::Runner::ContextEvalModule by default. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6730&group_id=797 From noreply at rubyforge.org Mon Nov 20 09:55:27 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 20 Nov 2006 09:55:27 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6730 ] Unable to use fixtures in context Message-ID: <20061120145527.E948F524184E@rubyforge.org> Bugs item #6730, was opened at 2006-11-17 11:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6730&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Yossef Mendelssohn (ymendel) Assigned to: David Chelimsky (dchelimsky) Summary: Unable to use fixtures in context Initial Comment: context "My Problem" do fixtures :my_problem end [ymendel]$ spec problem.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./problem.rb:2 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context.rb:14:in `initialize' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/extensions/kernel.rb:3:in `context' from ./problem.rb:1 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec:4 from /usr/local/bin/spec:18 I've seen a similar problem in bug 6411 (http://rubyforge.org/tracker/index.php?func=detail&aid=6411&group_id=797&atid=3149). The resolution there says it was fixed in r1088, and I'm using r1095 'gem list' returns rspec (0.7.2, 0.7.0) RSpec-0.7.2 (r1095) - BDD for Ruby http://rspec.rubyforge.org/ 'spec -v' returns RSpec-0.7.2 (r1095) - BDD for Ruby http://rspec.rubyforge.org/ ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 09:55 Message: Did you require File.dirname(__FILE__) + '/../spec_helper' in the top of your file? ---------------------------------------------------------------------- Comment By: Yossef Mendelssohn (ymendel) Date: 2006-11-20 09:02 Message: Ah, so it's not determining the context. However, my problem still exists if I try a spec in the models directory. Could it be that I'm using Engines and not plain vanilla Rails? I have my own spec_helper.rb that includes the line self.fixture_path = RAILS_ROOT + '/vendor/plugins/base/spec/fixtures' (instead of RAILS_ROOT + '/spec/fixtures') but maybe I need something to also point out the different path for the specs? Also, the paths listed on that page are a little confusing. Given that I'm in a 'spec' directory, the path should match '../spec/models/**/*_spec.rb', yes? If that's the case, the problem spec matches. irb confirms that. If there's something more, then I don't know. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 12:48 Message: The error points out that a Spec::Runner::ContextEvalModule is being invoked instead of a Spec::Rails::ModelContext, ::ControllerContext, ::HelperContext or ::ViewContext. The type of context is determined by the directory that the file is in. See http://rspec.rubyforge.org/documentation/rails/writing/index.html. If the path to the file is not in any of the paths listed on that page, the factory returns a Spec::Runner::ContextEvalModule by default. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6730&group_id=797 From aslak.hellesoy at gmail.com Mon Nov 20 10:00:24 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 20 Nov 2006 16:00:24 +0100 Subject: [rspec-devel] [rspec-users] artificial sugar causes cancer In-Reply-To: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com> References: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com> Message-ID: <8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com> On 11/19/06, David Chelimsky wrote: > All, > > If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 > you'll see that Chad (the submitter) found the source of the bug. > Unfortunately, the source of *this* bug is the *solution* to a > *previous bug* in which Rails was replacing RSpec's method missing > with its own. > > When we settled on underscores, my one reservation was that we'd keep > running into this particular problem - RSpec's method_missing > conflicting with others. > > I have a proposition that preserves the underscore syntax, makes some > examples even more clear, and eliminates this problem once and for > all. > > 1. Eliminate reliance on method missing to handle expectations by > adding all of the documented should_x_y_z methods directly to Object. > These would all delegate off to Spec::Expectations::Should, ::Not, > ::Have, etc, so the design wouldn't change much and Object itself, > though bloated w/ methods, would not be bloated w/ implementation. > > This would also give us a single expectations module that we add to > Object, providing several benefits including: > # more clarity in the API > # a place to put meaningful rdoc > # a potential formal plugin point > Good > 2. Change should_be to ONLY handle arbitrary predicates (not serve as > an alias for should_equal): > What would I say instead of flag.should_be true flag.should == true ? > subject.should_be :empty => passes if subject.empty? > subject.should_be :instance_of, SomeClass => passes if > subject.instance_of? SomeClass > etc... > > In my opinion (feel free to disagree), this actually makes these > examples more readable. Consider these two: > > @bdd_framework.should_be_adopted_quickly #current > @bdd_framework.should_be :adopted_quickly #proposed > I prefer the latter too > In my view, these read equally well from a language perspective AND > they make it easier for a developer to mentally separate the > expectation (should_be) from the expected value (adopted_quickly?). > > This WOULD require changes to existing specs. I think for those of you > who don't wrap expectation args in parens that a trivial script would > handle this for you. If you do use parens, the script might be more > complex. Perhaps if we *do* choose this direction, one of you would > like to contribute such a script. > > I fully recognize that this would cause some pain, but it is my > feeling that not addressing this leaves us in a crippled position in > which we commit to being sidetracked by this issue constantly > returning instead of focusing on enhancing the API. > > I also think that this is a better option than any of the following > that also crossed my mind: > * revert to dots > * figure out a sexy way to intercept all attempts to rewrite method > missing and re-inject RSpec's method missing in its place (perhaps > this does sound sexy, but I doth believe that there is a venereal > disease hiding in its midst) > * leave things as they are and continue to add ugly hacks like > NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get > so call it that) > * hang myself from the nearest bridge > Fortunately Illinois is quite flat. All of these are lame options. > Of course, if you have any solutions to propose, I'm all eyes. > > Thoughts? > I think this all sounds good. It would be great to lose our method_missing. It's not future-proof. Aslak > Thanks, > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From noreply at rubyforge.org Mon Nov 20 10:04:38 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 20 Nov 2006 10:04:38 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6780 ] routing() was failing...fix included Message-ID: <20061120150438.30467524189A@rubyforge.org> Bugs item #6780, was opened at 2006-11-19 09:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Gustav Paul (gustavpaul) Assigned to: David Chelimsky (dchelimsky) Summary: routing() was failing...fix included Initial Comment: Hey I have the following route in my config/routes.rb: map.connect 'login', :controller => 'member', :action => 'login' my spec looks as follows #no def setup or anything similar... specify "/member/login should route to /login" do routing(:controller => 'member', :action => 'login').should_eql "/login" end Was failing, reporting inequality of 47 and '/login' "/login"[0] happened to be char code 47 I've got the rails plugin installed as /vendor/plugins/rspec_on_rails In /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb line #131 Was: ActionController::Routing::Routes.generate(options)[0] changed to ActionController::Routing::Routes.generate(options) Working perfectly now... Might have introduced other bugs, but I though I'd let you guys know... Cheery-o Gustav Paul gustav at rails.co.za ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 10:04 Message: He's probably on edge rails. I think edge rails and 1.1.6 rails behave differently. In edge rails the [0] must go away. Maybe we need to do different things based on RAILS_VERSION or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-19 22:36 Message: Gustav - I added a spec for this and it passed right away. It's committed in revision (1126). What version of RSpec were you using when this happened? Trunk revision? Rails version? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 From noreply at rubyforge.org Mon Nov 20 10:06:03 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 20 Nov 2006 10:06:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6674 ] rspec_on_rails fails on @session deprecation warning? Message-ID: <20061120150603.2455D5241892@rubyforge.org> Bugs item #6674, was opened at 2006-11-14 13:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6674&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Steve Ross (sxross) Assigned to: Nobody (None) Summary: rspec_on_rails fails on @session deprecation warning? Initial Comment: rSpec 0.7.2 and rspec_on_rails 0.7.2 on Edge Rails (5473). I'm not certain that the deprecation warnings are causing this, but that's how it looks to me. By the way, the line 'puts self.class' outputs 'F'. Is this expected? Simple view test: require File.dirname(__FILE__) + '/../spec_helper' context "/member/index" do setup do @member = mock("member") @content_for_title = 'sign up for mailing list' @member.should_receive(:member) assigns[:member] = [@member] end specify "should show signup page" do puts self.class render '/member/index' response.should_have_tag 'div', attributes =>{:id => "intro"} end end Results: 1) RuntimeError in '/member/index should show signup page' Deprecating @session, but it's already set to #{}}>! Use the session= writer method instead of setting @session directly. /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1049:in `assign_deprecated_shortcuts' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1044:in `assign_deprecated_shortcuts' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1035:in `assign_shortcuts_without_flash' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/flash.rb:140:in `assign_shortcuts' Finished in 0.063727 seconds 1 specification, 1 failure rake aborted! Command failed with status (1): [/usr/local/bin/ruby -I"/usr/local/lib/ruby...] ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 10:06 Message: This is ZenTest's fault. This will go away when we get rid of ZenTest. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-19 15:30 Message: Moving this to bugs ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6674&group_id=797 From noreply at rubyforge.org Mon Nov 20 10:09:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 20 Nov 2006 10:09:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6730 ] Unable to use fixtures in context Message-ID: <20061120150914.16D3552418AD@rubyforge.org> Bugs item #6730, was opened at 2006-11-17 10:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6730&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Yossef Mendelssohn (ymendel) Assigned to: David Chelimsky (dchelimsky) Summary: Unable to use fixtures in context Initial Comment: context "My Problem" do fixtures :my_problem end [ymendel]$ spec problem.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./problem.rb:2 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context.rb:14:in `initialize' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/extensions/kernel.rb:3:in `context' from ./problem.rb:1 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec:4 from /usr/local/bin/spec:18 I've seen a similar problem in bug 6411 (http://rubyforge.org/tracker/index.php?func=detail&aid=6411&group_id=797&atid=3149). The resolution there says it was fixed in r1088, and I'm using r1095 'gem list' returns rspec (0.7.2, 0.7.0) RSpec-0.7.2 (r1095) - BDD for Ruby http://rspec.rubyforge.org/ 'spec -v' returns RSpec-0.7.2 (r1095) - BDD for Ruby http://rspec.rubyforge.org/ ---------------------------------------------------------------------- >Comment By: Yossef Mendelssohn (ymendel) Date: 2006-11-20 09:09 Message: Yes. The full file is as follows (between the comment lines): ### START OF SPEC (path == '/home/ymendel/core/trunk/vendor/plugins/base/spec/models/party_type_spec.rb') require File.dirname(__FILE__) + '/../spec_helper' context 'Party Types Model' do puts '----------------CONTEXT FIXTURE----------------' fixtures :party_types setup do end specify 'should create an instance of Party Type' do party_type = PartyType.new party_type.should_be_instance_of PartyType end end ### END OF SPEC The spec helper is as follows: ### START OF SPEC HELPER (path == '/home/ymendel/core/trunk/vendor/plugins/base/spec/spec_helper.rb') puts '----------------SPEC HELPER----------------' ENV['RAILS_ENV'] = 'test' require File.dirname(__FILE__) + '/../../../../config/environment' require 'rspec_on_rails' # Even if you're using RSpec, RSpec on Rails is reusing some of the # Rails-specific extensions for fixtures and stubbed requests, response # and other things (via RSpec's inherit mechanism). These extensions are # tightly coupled to Test::Unit in Rails, which is why you're seeing it here. module Test module Rails class TestCase < Test::Unit::TestCase self.use_transactional_fixtures = true self.use_instantiated_fixtures = false self.fixture_path = RAILS_ROOT + '/vendor/plugins/base/spec/fixtures' # You can set up your global fixtures here, or you # can do it in individual contexts # fixtures :table_a, :table_b puts '----------------HELPER FIXTURES----------------' fixtures :party_types end end end ### END OF SPEC HELPER And the output is as follows: [ymendel]$ spec models/party_type_spec.rb ----------------SPEC HELPER---------------- Test Database User [ymendel] PATCH: Capistrano logging command permissions. (capistrano_base.rb) PATCH: Javascript include spacing. (asset_tag_helper_override.rb) PATCH: Field error proc. (field_with_errors_patch.rb) PATCH: Modifying update/create/destroy methods to include wrapping points (update_create_destroy_wrapping.rb) PATCH: Quoting acts_as_list scoping (list.rb) PATCH: Modifying habtm to select all association fields (habtm_select.rb) PATCH: Modifying Oracle adapter to get data length of CHAR columns (oracle_adapter_columns.rb) ----------------HELPER FIXTURES---------------- ----------------CONTEXT FIXTURE---------------- /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:13:in `_method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/expectations/sugar.rb:9:in `method_missing' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context_eval.rb:37:in `method_missing' from ./models/party_type_spec.rb:6 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/context.rb:14:in `initialize' from ./models/../../../../../config/../vendor/plugins/rspec/lib/spec/rails/context_factory.rb:18:in `create' from /home/ymendel/core/trunk/vendor/plugins/rspec/lib/extensions/kernel.rb:4:in `context' from ./models/party_type_spec.rb:3 from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec:4 from /usr/local/bin/spec:18 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 08:55 Message: Did you require File.dirname(__FILE__) + '/../spec_helper' in the top of your file? ---------------------------------------------------------------------- Comment By: Yossef Mendelssohn (ymendel) Date: 2006-11-20 08:02 Message: Ah, so it's not determining the context. However, my problem still exists if I try a spec in the models directory. Could it be that I'm using Engines and not plain vanilla Rails? I have my own spec_helper.rb that includes the line self.fixture_path = RAILS_ROOT + '/vendor/plugins/base/spec/fixtures' (instead of RAILS_ROOT + '/spec/fixtures') but maybe I need something to also point out the different path for the specs? Also, the paths listed on that page are a little confusing. Given that I'm in a 'spec' directory, the path should match '../spec/models/**/*_spec.rb', yes? If that's the case, the problem spec matches. irb confirms that. If there's something more, then I don't know. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 11:48 Message: The error points out that a Spec::Runner::ContextEvalModule is being invoked instead of a Spec::Rails::ModelContext, ::ControllerContext, ::HelperContext or ::ViewContext. The type of context is determined by the directory that the file is in. See http://rspec.rubyforge.org/documentation/rails/writing/index.html. If the path to the file is not in any of the paths listed on that page, the factory returns a Spec::Runner::ContextEvalModule by default. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6730&group_id=797 From dchelimsky at gmail.com Mon Nov 20 11:13:08 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 20 Nov 2006 10:13:08 -0600 Subject: [rspec-devel] [rspec-users] artificial sugar causes cancer In-Reply-To: <8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com> References: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com> <8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com> Message-ID: <57c63afe0611200813q3e34c06eu57db39bb863484f9@mail.gmail.com> On 11/20/06, aslak hellesoy wrote: > On 11/19/06, David Chelimsky wrote: > > All, > > > > If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 > > you'll see that Chad (the submitter) found the source of the bug. > > Unfortunately, the source of *this* bug is the *solution* to a > > *previous bug* in which Rails was replacing RSpec's method missing > > with its own. > > > > When we settled on underscores, my one reservation was that we'd keep > > running into this particular problem - RSpec's method_missing > > conflicting with others. > > > > I have a proposition that preserves the underscore syntax, makes some > > examples even more clear, and eliminates this problem once and for > > all. > > > > 1. Eliminate reliance on method missing to handle expectations by > > adding all of the documented should_x_y_z methods directly to Object. > > These would all delegate off to Spec::Expectations::Should, ::Not, > > ::Have, etc, so the design wouldn't change much and Object itself, > > though bloated w/ methods, would not be bloated w/ implementation. > > > > This would also give us a single expectations module that we add to > > Object, providing several benefits including: > > # more clarity in the API > > # a place to put meaningful rdoc > > # a potential formal plugin point > > > > Good > > > 2. Change should_be to ONLY handle arbitrary predicates (not serve as > > an alias for should_equal): > > > > What would I say instead of flag.should_be true > flag.should == true Actually, should_be is currently an alias for should_equal. We could let it continue to be so for everything but a symbol, in which case it would find a matching predicate method on the target. This would lead to: subject.should_be true subject.should_be false subject.should_be nil subject.should_be :using_a_symbol #subject.using_a_symbol? etc > > ? > > > subject.should_be :empty => passes if subject.empty? > > subject.should_be :instance_of, SomeClass => passes if > > subject.instance_of? SomeClass > > etc... > > > > In my opinion (feel free to disagree), this actually makes these > > examples more readable. Consider these two: > > > > @bdd_framework.should_be_adopted_quickly #current > > @bdd_framework.should_be :adopted_quickly #proposed > > > > I prefer the latter too > > > In my view, these read equally well from a language perspective AND > > they make it easier for a developer to mentally separate the > > expectation (should_be) from the expected value (adopted_quickly?). > > > > This WOULD require changes to existing specs. I think for those of you > > who don't wrap expectation args in parens that a trivial script would > > handle this for you. If you do use parens, the script might be more > > complex. Perhaps if we *do* choose this direction, one of you would > > like to contribute such a script. > > > > I fully recognize that this would cause some pain, but it is my > > feeling that not addressing this leaves us in a crippled position in > > which we commit to being sidetracked by this issue constantly > > returning instead of focusing on enhancing the API. > > > > I also think that this is a better option than any of the following > > that also crossed my mind: > > * revert to dots > > * figure out a sexy way to intercept all attempts to rewrite method > > missing and re-inject RSpec's method missing in its place (perhaps > > this does sound sexy, but I doth believe that there is a venereal > > disease hiding in its midst) > > * leave things as they are and continue to add ugly hacks like > > NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get > > so call it that) > > * hang myself from the nearest bridge > > > > Fortunately Illinois is quite flat. All of these are lame options. > > > Of course, if you have any solutions to propose, I'm all eyes. > > > > Thoughts? > > > > I think this all sounds good. It would be great to lose our > method_missing. It's not future-proof. It's not even present proof! Thanks, David > > Aslak > > > Thanks, > > David > > _______________________________________________ > > 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 > From noreply at rubyforge.org Mon Nov 20 11:50:37 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 20 Nov 2006 11:50:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6791 ] stub return values for all instances of a class Message-ID: <20061120165037.D86CE52419E2@rubyforge.org> Feature Requests item #6791, was opened at 2006-11-20 16:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6791&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: stub return values for all instances of a class Initial Comment: I'd like to be able to do this: SomeClass.stub_instance_method!(:method_name).and_return(specified_value) (syntax just a suggestion) This should set up a world in which all instances of SomeClass return specified_value for any calls to :method_name. This differs from SomeClass.stub! in that it applies to instance methods rather than class methods. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6791&group_id=797 From wilsonb at gmail.com Mon Nov 20 15:06:03 2006 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Mon, 20 Nov 2006 15:06:03 -0500 Subject: [rspec-devel] underscores, sugar, and more and more bugs In-Reply-To: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> Message-ID: On 11/19/06, David Chelimsky wrote: > I sent this earlier under with the subject "artificial sugar causes > cancer" and I think some spam filters ate it. Here it is again: > ====================================== > > All, > > If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 > you'll see that Chad (the submitter) found the source of the bug. > Unfortunately, the source of *this* bug is the *solution* to a > *previous bug* in which Rails was replacing RSpec's method missing > with its own. > > When we settled on underscores, my one reservation was that we'd keep > running into this particular problem - RSpec's method_missing > conflicting with others. > My opinion remains something like this: 1. Do away with underscores that require method_missing. 2. Implement all non-dynamic 'should' methods directly on Object. 3. Split anything dynamic with a period. e.g. @thing.should_arbitrary_predicate becomes @thing.should.arbitrary_predicate However, @thing.should_have(3).things would remain unchanged. sugar.rb is a nightmare. As evidence, I present the fact that my original .method_should_be_changed_by {block} patch was rejected because it needed to modify sugar.rb. Even the core team doesn't want to touch it. :) From dchelimsky at gmail.com Mon Nov 20 15:14:27 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 20 Nov 2006 14:14:27 -0600 Subject: [rspec-devel] underscores, sugar, and more and more bugs In-Reply-To: References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> Message-ID: <57c63afe0611201214o71d0918q8834871886fae093@mail.gmail.com> On 11/20/06, Wilson Bilkovich wrote: > On 11/19/06, David Chelimsky wrote: > > I sent this earlier under with the subject "artificial sugar causes > > cancer" and I think some spam filters ate it. Here it is again: > > ====================================== > > > > All, > > > > If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 > > you'll see that Chad (the submitter) found the source of the bug. > > Unfortunately, the source of *this* bug is the *solution* to a > > *previous bug* in which Rails was replacing RSpec's method missing > > with its own. > > > > When we settled on underscores, my one reservation was that we'd keep > > running into this particular problem - RSpec's method_missing > > conflicting with others. > > > > My opinion remains something like this: > 1. Do away with underscores that require method_missing. > 2. Implement all non-dynamic 'should' methods directly on Object. > 3. Split anything dynamic with a period. > > e.g. > @thing.should_arbitrary_predicate becomes @thing.should.arbitrary_predicate > However, @thing.should_have(3).things would remain unchanged. Do you see a substantial difference between these two: @thing.should_be :arbitrary_predicate @thing.should_be.arbitrary_predicate > > sugar.rb is a nightmare. As evidence, I present the fact that my > original .method_should_be_changed_by {block} patch was rejected > because it needed to modify sugar.rb. > > Even the core team doesn't want to touch it. :) > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From nicksieger at gmail.com Mon Nov 20 15:36:02 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Mon, 20 Nov 2006 14:36:02 -0600 Subject: [rspec-devel] underscores, sugar, and more and more bugs In-Reply-To: References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> Message-ID: On 11/20/06, Wilson Bilkovich wrote: > > > My opinion remains something like this: > 1. Do away with underscores that require method_missing. > 2. Implement all non-dynamic 'should' methods directly on Object. > 3. Split anything dynamic with a period. I agree with this, thanks for summing it up more succintly than I was able to earlier. sugar.rb is a nightmare. As evidence, I present the fact that my > original .method_should_be_changed_by {block} patch was rejected > because it needed to modify sugar.rb. > > Even the core team doesn't want to touch it. :) Is this a remant from that fateful drunken night of Steve's that birthed RSpec? :-) /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061120/497587ee/attachment.html From dchelimsky at gmail.com Mon Nov 20 15:46:16 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 20 Nov 2006 14:46:16 -0600 Subject: [rspec-devel] underscores, sugar, and more and more bugs In-Reply-To: References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> Message-ID: <57c63afe0611201246i561096d6v1fb6d80c35bcf57a@mail.gmail.com> On 11/20/06, Nick Sieger wrote: > On 11/20/06, Wilson Bilkovich wrote: > > > > My opinion remains something like this: > > 1. Do away with underscores that require method_missing. > > 2. Implement all non-dynamic 'should' methods directly on Object. > > 3. Split anything dynamic with a period. > > > I agree with this, thanks for summing it up more succintly than I was able > to earlier. Again, does anyone see a big difference between: @thing.should_be.something @thing.should_be :something For me, the latter cleanly separates what is framework (should_be) from what is supposed to be in your code (:something) Either allows us to eliminate method_missing, so this is purely a syntax question. Thanks, David > > > sugar.rb is a nightmare. As evidence, I present the fact that my > > original .method_should_be_changed_by {block} patch was rejected > > because it needed to modify sugar.rb. > > > > Even the core team doesn't want to touch it. :) > > Is this a remant from that fateful drunken night of Steve's that birthed > RSpec? :-) Mini-history: 1. Steve's drunken brainchild was all the methods right on Object 2. I introduced should_be.arbitrary_predicate 3. We decided to make it all dots: should.be.arbitrary_predicate, should.equal, etc. This allowed us to unclutter Object and make the underlying implementation more OO 4. dot-hater Rich Kilmer provided the very sexy sugar module 5. we went all underscores using sugar I want to point out that sugar is no less sexy now than it was to begin with. The problem is that rspec has to support other frameworks like rails that do the same sexy stuff, hence the conflicts. I think the lesson, for me, is that sexy is not always that sexy in a framework. > > /Nick > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From nicksieger at gmail.com Mon Nov 20 16:11:50 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Mon, 20 Nov 2006 15:11:50 -0600 Subject: [rspec-devel] underscores, sugar, and more and more bugs In-Reply-To: <57c63afe0611201246i561096d6v1fb6d80c35bcf57a@mail.gmail.com> References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> <57c63afe0611201246i561096d6v1fb6d80c35bcf57a@mail.gmail.com> Message-ID: On 11/20/06, David Chelimsky wrote: > > > Again, does anyone see a big difference between: > > @thing.should_be.something > @thing.should_be :something > > For me, the latter cleanly separates what is framework (should_be) > from what is supposed to be in your code (:something) Now that you put it that way...no. Either allows us to eliminate method_missing, so this is purely a > syntax question. Yep, and I don't wish to make a bikeshed out of this issue, but what do you think about supporting both? /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061120/9845e353/attachment.html From wilsonb at gmail.com Mon Nov 20 16:13:49 2006 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Mon, 20 Nov 2006 16:13:49 -0500 Subject: [rspec-devel] underscores, sugar, and more and more bugs In-Reply-To: <57c63afe0611201214o71d0918q8834871886fae093@mail.gmail.com> References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> <57c63afe0611201214o71d0918q8834871886fae093@mail.gmail.com> Message-ID: On 11/20/06, David Chelimsky wrote: > On 11/20/06, Wilson Bilkovich wrote: > > On 11/19/06, David Chelimsky wrote: > > > I sent this earlier under with the subject "artificial sugar causes > > > cancer" and I think some spam filters ate it. Here it is again: > > > ====================================== > > > > > > All, > > > > > > If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 > > > you'll see that Chad (the submitter) found the source of the bug. > > > Unfortunately, the source of *this* bug is the *solution* to a > > > *previous bug* in which Rails was replacing RSpec's method missing > > > with its own. > > > > > > When we settled on underscores, my one reservation was that we'd keep > > > running into this particular problem - RSpec's method_missing > > > conflicting with others. > > > > > > > My opinion remains something like this: > > 1. Do away with underscores that require method_missing. > > 2. Implement all non-dynamic 'should' methods directly on Object. > > 3. Split anything dynamic with a period. > > > > e.g. > > @thing.should_arbitrary_predicate becomes @thing.should.arbitrary_predicate > > However, @thing.should_have(3).things would remain unchanged. > > Do you see a substantial difference between these two: > > @thing.should_be :arbitrary_predicate > @thing.should_be.arbitrary_predicate > I personally much prefer @thing.should_be.predicate, partly because it makes it easier to do refactorings in my editor. Use of symbols there means there are really two kinds of method call. The justification I've heard for :predicate is that it makes it clearer which part is the expectation, and which is part of the framework. Correct? Why do I, as a user, care about that distinction? I just want the line of code to read like a sentence. I don't care about how it is implemented. Also, the symbol form leads to another stylistic argument waiting to happen when working with a team: @thing.should_be(:something), or @thing.should_be :something etc etc. Chaos ensues. From dchelimsky at gmail.com Mon Nov 20 16:59:16 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 20 Nov 2006 15:59:16 -0600 Subject: [rspec-devel] underscores, sugar, and more and more bugs In-Reply-To: References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> <57c63afe0611201246i561096d6v1fb6d80c35bcf57a@mail.gmail.com> Message-ID: <57c63afe0611201359n23a3b9f3rba3a150a60806bfe@mail.gmail.com> On 11/20/06, Nick Sieger wrote: > On 11/20/06, David Chelimsky wrote: > > > > Again, does anyone see a big difference between: > > > > @thing.should_be.something > > @thing.should_be :something > > > > For me, the latter cleanly separates what is framework (should_be) > > from what is supposed to be in your code (:something) > > Now that you put it that way...no. > > > Either allows us to eliminate method_missing, so this is purely a > > syntax question. > > Yep, and I don't wish to make a bikeshed out of this issue, but what do you > think about supporting both? In my experience, supporting 2 ways to do the same thing makes it confusing to understand how to use, binds implementation to more API, leads to more hackage under the hood. I feel bad about it. > > /Nick > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From wilsonb at gmail.com Mon Nov 20 17:29:30 2006 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Mon, 20 Nov 2006 17:29:30 -0500 Subject: [rspec-devel] underscores, sugar, and more and more bugs In-Reply-To: <57c63afe0611201359n23a3b9f3rba3a150a60806bfe@mail.gmail.com> References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> <57c63afe0611201246i561096d6v1fb6d80c35bcf57a@mail.gmail.com> <57c63afe0611201359n23a3b9f3rba3a150a60806bfe@mail.gmail.com> Message-ID: On 11/20/06, David Chelimsky wrote: > On 11/20/06, Nick Sieger wrote: > > On 11/20/06, David Chelimsky wrote: > > > > > > Again, does anyone see a big difference between: > > > > > > @thing.should_be.something > > > @thing.should_be :something > > > > > > For me, the latter cleanly separates what is framework (should_be) > > > from what is supposed to be in your code (:something) > > > > Now that you put it that way...no. > > > > > Either allows us to eliminate method_missing, so this is purely a > > > syntax question. > > > > Yep, and I don't wish to make a bikeshed out of this issue, but what do you > > think about supporting both? > > In my experience, supporting 2 ways to do the same thing makes it > confusing to understand how to use, binds implementation to more API, > leads to more hackage under the hood. I feel bad about it. > I think that the current issue with underscores shows that picking one way is often the best answer. :) --Wilson. From brian.takita at gmail.com Mon Nov 20 20:43:21 2006 From: brian.takita at gmail.com (Brian Takita) Date: Mon, 20 Nov 2006 17:43:21 -0800 Subject: [rspec-devel] underscores, sugar, and more and more bugs In-Reply-To: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> Message-ID: <1d7ddd110611201743i1aba6d18h56440b6a8ba7bee6@mail.gmail.com> On 11/19/06, David Chelimsky wrote: > > I sent this earlier under with the subject "artificial sugar causes > cancer" and I think some spam filters ate it. Here it is again: > ====================================== > > All, > > If you look at > http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 > you'll see that Chad (the submitter) found the source of the bug. > Unfortunately, the source of *this* bug is the *solution* to a > *previous bug* in which Rails was replacing RSpec's method missing > with its own. > > When we settled on underscores, my one reservation was that we'd keep > running into this particular problem - RSpec's method_missing > conflicting with others. > > I have a proposition that preserves the underscore syntax, makes some > examples even more clear, and eliminates this problem once and for > all. > > 1. Eliminate reliance on method missing to handle expectations by > adding all of the documented should_x_y_z methods directly to Object. > These would all delegate off to Spec::Expectations::Should, ::Not, > ::Have, etc, so the design wouldn't change much and Object itself, > though bloated w/ methods, would not be bloated w/ implementation. > > This would also give us a single expectations module that we add to > Object, providing several benefits including: > # more clarity in the API > # a place to put meaningful rdoc > # a potential formal plugin point > > 2. Change should_be to ONLY handle arbitrary predicates (not serve as > an alias for should_equal): > > subject.should_be :empty => passes if subject.empty? > subject.should_be :instance_of, SomeClass => passes if > subject.instance_of? SomeClass > etc... > > In my opinion (feel free to disagree), this actually makes these > examples more readable. Consider these two: > > @bdd_framework.should_be_adopted_quickly #current > @bdd_framework.should_be :adopted_quickly #proposed I was looking through Dave Astel's Mastermind tutorial. In it he had the method win? should_be :win seems clunky. I suppose that should_be supports past tense: should_be :won and should supports present tense: should :win Regarding the adopted_quickly example its: should_be :adopted_quickly and should :adopt_quickly I imagine that most of these boolean (?) methods are in present tense. In my view, these read equally well from a language perspective AND > they make it easier for a developer to mentally separate the > expectation (should_be) from the expected value (adopted_quickly?). > > This WOULD require changes to existing specs. I think for those of you > who don't wrap expectation args in parens that a trivial script would > handle this for you. If you do use parens, the script might be more > complex. Perhaps if we *do* choose this direction, one of you would > like to contribute such a script. > > I fully recognize that this would cause some pain, but it is my > feeling that not addressing this leaves us in a crippled position in > which we commit to being sidetracked by this issue constantly > returning instead of focusing on enhancing the API. > > I also think that this is a better option than any of the following > that also crossed my mind: > * revert to dots > * figure out a sexy way to intercept all attempts to rewrite method > missing and re-inject RSpec's method missing in its place (perhaps > this does sound sexy, but I doth believe that there is a venereal > disease hiding in its midst) > * leave things as they are and continue to add ugly hacks like > NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get > so call it that) > * hang myself from the nearest bridge > > Of course, if you have any solutions to propose, I'm all eyes. > > Thoughts? > > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061120/0ca85cea/attachment.html From brian.takita at gmail.com Mon Nov 20 21:07:34 2006 From: brian.takita at gmail.com (Brian Takita) Date: Mon, 20 Nov 2006 18:07:34 -0800 Subject: [rspec-devel] Rspec Brown Bag Message-ID: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> Hello, I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see Dave Astel's talk as well as several of my coworkers. The developers at my workplace are experienced Agile developers. What would be some good things to focus on for this brown bag? Are there slides to presentations that would be useful? Any resistance/skepticism, and how to best address these concerns? I'm kindof nervous because there is some skepticism toward rspec and BDD. Mainly: - Test::Unit already does that, so why do we need rspec? - It's not production ready. (Stack traces are too cluttered for RspecOnRails; although this opinion was based on version 0.6) - New people will be confused seeing rspec code (although this is solved by more education, usage, encapsulation, etc.) - BDD is TDD using "should" instead of "assert" There are also a number of people who do see benefits to using rspec and are excited by it, so I do have "allies". :) I'm particularly interested in showing: - How BDD is really good TDD without sounding religious - How rspec encourages developers to create better "tests" than Test::Unit Thank you, Brian Takita -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061120/f45ad744/attachment.html From brian.takita at gmail.com Mon Nov 20 21:23:49 2006 From: brian.takita at gmail.com (Brian Takita) Date: Mon, 20 Nov 2006 18:23:49 -0800 Subject: [rspec-devel] underscores, sugar, and more and more bugs In-Reply-To: <1d7ddd110611201743i1aba6d18h56440b6a8ba7bee6@mail.gmail.com> References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com> <1d7ddd110611201743i1aba6d18h56440b6a8ba7bee6@mail.gmail.com> Message-ID: <1d7ddd110611201823n422a4903ibab932a40b7bf14e@mail.gmail.com> On 11/20/06, Brian Takita wrote: > > On 11/19/06, David Chelimsky wrote: > > > I sent this earlier under with the subject "artificial sugar causes > > cancer" and I think some spam filters ate it. Here it is again: > > ====================================== > > > > All, > > > > If you look at > > http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149 > > you'll see that Chad (the submitter) found the source of the bug. > > Unfortunately, the source of *this* bug is the *solution* to a > > *previous bug* in which Rails was replacing RSpec's method missing > > with its own. > > > > When we settled on underscores, my one reservation was that we'd keep > > running into this particular problem - RSpec's method_missing > > conflicting with others. > > > > I have a proposition that preserves the underscore syntax, makes some > > examples even more clear, and eliminates this problem once and for > > all. > > > > 1. Eliminate reliance on method missing to handle expectations by > > adding all of the documented should_x_y_z methods directly to Object. > > These would all delegate off to Spec::Expectations::Should, ::Not, > > ::Have, etc, so the design wouldn't change much and Object itself, > > though bloated w/ methods, would not be bloated w/ implementation. > > > > This would also give us a single expectations module that we add to > > Object, providing several benefits including: > > # more clarity in the API > > # a place to put meaningful rdoc > > # a potential formal plugin point > > > > 2. Change should_be to ONLY handle arbitrary predicates (not serve as > > an alias for should_equal): > > > > subject.should_be :empty => passes if subject.empty? > > subject.should_be :instance_of, SomeClass => passes if > > subject.instance_of? SomeClass > > etc... > > > > In my opinion (feel free to disagree), this actually makes these > > examples more readable. Consider these two: > > > > @bdd_framework.should_be_adopted_quickly #current > > @bdd_framework.should_be :adopted_quickly #proposed > > > I was looking through Dave Astel's Mastermind tutorial. In it he had the > method win? > should_be :win > seems clunky. I suppose that should_be supports past tense: > should_be :won > and should supports present tense: > should :win > > Regarding the adopted_quickly example its: > should_be :adopted_quickly > and > should :adopt_quickly > It also looks like should_be works with adjectives and past tense verbs with adverbs. should be black? should be adopted quickly? should seems to support using present tense verbs posed as a question. should adopt? I apologize if this is old stuff that was already discussed. I imagine that most of these boolean (?) methods are in present tense. > > In my view, these read equally well from a language perspective AND > > they make it easier for a developer to mentally separate the > > expectation (should_be) from the expected value (adopted_quickly?). > > > > This WOULD require changes to existing specs. I think for those of you > > who don't wrap expectation args in parens that a trivial script would > > handle this for you. If you do use parens, the script might be more > > complex. Perhaps if we *do* choose this direction, one of you would > > like to contribute such a script. > > > > I fully recognize that this would cause some pain, but it is my > > feeling that not addressing this leaves us in a crippled position in > > which we commit to being sidetracked by this issue constantly > > returning instead of focusing on enhancing the API. > > > > I also think that this is a better option than any of the following > > that also crossed my mind: > > * revert to dots > > * figure out a sexy way to intercept all attempts to rewrite method > > missing and re-inject RSpec's method missing in its place (perhaps > > this does sound sexy, but I doth believe that there is a venereal > > disease hiding in its midst) > > * leave things as they are and continue to add ugly hacks like > > NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get > > so call it that) > > * hang myself from the nearest bridge > > > > Of course, if you have any solutions to propose, I'm all eyes. > > > > Thoughts? > > > > Thanks, > > David > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061120/70ec1fa9/attachment-0001.html From srbaker at pobox.com Mon Nov 20 21:17:31 2006 From: srbaker at pobox.com (Steven Baker) Date: Mon, 20 Nov 2006 18:17:31 -0800 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> Message-ID: Not sure if you saw my RejectConf lightning talk, but I have a (poor) video of it. :P -Steven On 20-Nov-06, at 6:07 PM, Brian Takita wrote: > Hello, > > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for > my company (Pivotal Computer Systems, http://www.pivotalsf.com). I > did see Dave Astel's talk as well as several of my coworkers. > The developers at my workplace are experienced Agile developers. > > What would be some good things to focus on for this brown bag? > Are there slides to presentations that would be useful? > Any resistance/skepticism, and how to best address these concerns? > > I'm kindof nervous because there is some skepticism toward rspec > and BDD. > > Mainly: > Test::Unit already does that, so why do we need rspec? > It's not production ready. (Stack traces are too cluttered for > RspecOnRails; although this opinion was based on version 0.6) > New people will be confused seeing rspec code (although this is > solved by more education, usage, encapsulation, etc.) > BDD is TDD using "should" instead of "assert" > There are also a number of people who do see benefits to using > rspec and are excited by it, so I do have "allies". :) > > I'm particularly interested in showing: > How BDD is really good TDD without sounding religious > How rspec encourages developers to create better "tests" than > Test::Unit > Thank you, > Brian Takita > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061120/71d5b803/attachment.html From brian.takita at gmail.com Mon Nov 20 22:35:58 2006 From: brian.takita at gmail.com (Brian Takita) Date: Mon, 20 Nov 2006 19:35:58 -0800 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> Message-ID: <1d7ddd110611201935i2840fbc6t61779c8233a18e0c@mail.gmail.com> On 11/20/06, Steven Baker wrote: > > Not sure if you saw my RejectConf lightning talk, but I have a (poor) > video of it. :P > Yes I saw it. Do you have the video posted somewhere? -Steven > On 20-Nov-06, at 6:07 PM, Brian Takita wrote: > > Hello, > > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my > company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see > Dave Astel's talk as well as several of my coworkers. > The developers at my workplace are experienced Agile developers. > > What would be some good things to focus on for this brown bag? > Are there slides to presentations that would be useful? > Any resistance/skepticism, and how to best address these concerns? > > I'm kindof nervous because there is some skepticism toward rspec and BDD. > > Mainly: > > - Test::Unit already does that, so why do we need rspec? > - It's not production ready. (Stack traces are too cluttered for > RspecOnRails; although this opinion was based on version 0.6) > - New people will be confused seeing rspec code (although this is > solved by more education, usage, encapsulation, etc.) > - BDD is TDD using "should" instead of "assert" > > There are also a number of people who do see benefits to using rspec and > are excited by it, so I do have "allies". :) > > I'm particularly interested in showing: > > - How BDD is really good TDD without sounding religious > - How rspec encourages developers to create better "tests" than > Test::Unit > > Thank you, > Brian Takita > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061120/c2978e26/attachment.html From srbaker at pobox.com Mon Nov 20 22:55:29 2006 From: srbaker at pobox.com (Steven Baker) Date: Mon, 20 Nov 2006 19:55:29 -0800 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: <1d7ddd110611201935i2840fbc6t61779c8233a18e0c@mail.gmail.com> References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> <1d7ddd110611201935i2840fbc6t61779c8233a18e0c@mail.gmail.com> Message-ID: > On 11/20/06, Steven Baker wrote: > Not sure if you saw my RejectConf lightning talk, but I have a > (poor) video of it. :P > > Yes I saw it. Do you have the video posted somewhere? It's on the way to my webspace. I'll link you shortly. -Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061120/21086741/attachment.html From dchelimsky at gmail.com Tue Nov 21 00:29:23 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 20 Nov 2006 23:29:23 -0600 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> Message-ID: <57c63afe0611202129v74b14feancd9aefaa7bc33b38@mail.gmail.com> On 11/20/06, Brian Takita wrote: > Hello, > > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my > company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see Dave > Astel's talk as well as several of my coworkers. > The developers at my workplace are experienced Agile developers. > > What would be some good things to focus on for this brown bag? > Are there slides to presentations that would be useful? > Any resistance/skepticism, and how to best address these concerns? > > I'm kindof nervous because there is some skepticism toward rspec and BDD. > > Mainly: > > Test::Unit already does that, so why do we need rspec? The whole context/specify thing makes you see "testing" in a different way. Sure, you can create multiple test cases to represent different contexts, but by naming them in text, they become easier to read and therefore easier to grok. > It's not production ready. (Stack traces are too cluttered for RspecOnRails; > although this opinion was based on version 0.6) To some degree this seems true to me to me. While, with a few exceptions, the rspec core API is quite stable now, the rails plugin is quite volatile. For that reason, I think there is some risk to adopting the rails plugin right now. It really depends on your team and what the team values are. There is a lot to be gained from early adoption. You just have to have that mindset. > New people will be confused seeing rspec code (although this is solved by > more education, usage, encapsulation, etc.) > BDD is TDD using "should" instead of "assert" If all that you know of BDD is rspec, that's an easy misunderstanding to have. I'd give Dan North's blog a read to help understand the greater context. In the end it's about language and collaboration between technical people and non-technical people. Also, even as a granular, developer practice (absent the wider team piece), rspec offers clarity in the way you organize your specs (by context). It offers clarity in the expression of expectations (actual.should == expected vs assert_equal(:am_i_expected_or_actual, :am_i_actual_or_expected). > There are also a number of people who do see benefits to using rspec and are > excited by it, so I do have "allies". :) > > I'm particularly interested in showing: > > How BDD is really good TDD without sounding religious > How rspec encourages developers to create better "tests" than Focus on your own experience. Do you believe that BDD changes the conversation? Do you believe that you write better tests (if you MUST call them that) because rspec encourages you to do so? If so, then try to tap that. How are they better? Are you writing better code? Are your designs simpler? Are they easier to change later? Etc, etc. If the answer to these things is no, then you probably shouldn't be evangelizing it. That would be dishonest. Just tell people about it and what your experience is either way (the things you like, the things you don't). 2 cents. > Test::UnitThank you, > Brian Takita > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From bkeepers at gmail.com Tue Nov 21 01:13:58 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Tue, 21 Nov 2006 01:13:58 -0500 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> Message-ID: <6E4B61B7-C59B-4CC5-817D-AF5619AB83F4@gmail.com> One of the things that has sold me on rspec--besides the fact that it encourages better tests--is the ability to print out the specs from your app. For example, the following are the start of some specs for an ecommerce app I am working on. I can take my tests (specs derived from user stories) and generate documentation that I can hand directly to the customer, and it makes perfect sense to them. There is no question as to what the app does and whether or not the specs are up to date. That alone is worth it's weight in gold. A user - can purchase items - should have many orders A user purchasing items - should create an order - should add to the user's orders - should create line items - should set line item amount to the item's price - should set line item amount to 0 if item does not have a price An order - should have line_items - should have an invoice - should be invalid without an amount An invoice - should have many orders - should be invalid without an amount - should have many payments - should belong to a user Paying an invoice - should create a payment - should set payment amount equal to invoice amount - should set payment confirmation number Calling invoice.pay with an invalid credit card - should raise AuthorizationError A payment - should belong to an invoice - should be invalid without an amount Brandon On Nov 20, 2006, at 9:07 PM, Brian Takita wrote: > Hello, > > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for > my company (Pivotal Computer Systems, http://www.pivotalsf.com). I > did see Dave Astel's talk as well as several of my coworkers. > The developers at my workplace are experienced Agile developers. > > What would be some good things to focus on for this brown bag? > Are there slides to presentations that would be useful? > Any resistance/skepticism, and how to best address these concerns? > > I'm kindof nervous because there is some skepticism toward rspec > and BDD. > > Mainly: > Test::Unit already does that, so why do we need rspec? > It's not production ready. (Stack traces are too cluttered for > RspecOnRails; although this opinion was based on version 0.6) > New people will be confused seeing rspec code (although this is > solved by more education, usage, encapsulation, etc.) > BDD is TDD using "should" instead of "assert" > There are also a number of people who do see benefits to using > rspec and are excited by it, so I do have "allies". :) > > I'm particularly interested in showing: > How BDD is really good TDD without sounding religious > How rspec encourages developers to create better "tests" than > Test::Unit > Thank you, > Brian Takita > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From brian.takita at gmail.com Tue Nov 21 01:38:19 2006 From: brian.takita at gmail.com (Brian Takita) Date: Mon, 20 Nov 2006 22:38:19 -0800 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: <57c63afe0611202129v74b14feancd9aefaa7bc33b38@mail.gmail.com> References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> <57c63afe0611202129v74b14feancd9aefaa7bc33b38@mail.gmail.com> Message-ID: <1d7ddd110611202238y77c6af08j71b27cf9150b2ba@mail.gmail.com> On 11/20/06, David Chelimsky wrote: > > On 11/20/06, Brian Takita wrote: > > Hello, > > > > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my > > company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see > Dave > > Astel's talk as well as several of my coworkers. > > The developers at my workplace are experienced Agile developers. > > > > What would be some good things to focus on for this brown bag? > > Are there slides to presentations that would be useful? > > Any resistance/skepticism, and how to best address these concerns? > > > > I'm kindof nervous because there is some skepticism toward rspec and > BDD. > > > > Mainly: > > > > Test::Unit already does that, so why do we need rspec? > > The whole context/specify thing makes you see "testing" in a different > way. Sure, you can create multiple test cases to represent different > contexts, but by naming them in text, they become easier to read and > therefore easier to grok. I like that. It goes into the intent of the code. It seems even more important when pairs are switched frequently. > It's not production ready. (Stack traces are too cluttered for > RspecOnRails; > > although this opinion was based on version 0.6) > > To some degree this seems true to me to me. While, with a few > exceptions, the rspec core API is quite stable now, the rails plugin > is quite volatile. For that reason, I think there is some risk to > adopting the rails plugin right now. It really depends on your team > and what the team values are. There is a lot to be gained from early > adoption. You just have to have that mindset. That makes sense. It seems like the best opportunity to use rspec on rails would be in starting a new project. > New people will be confused seeing rspec code (although this is solved by > > more education, usage, encapsulation, etc.) > > BDD is TDD using "should" instead of "assert" > > If all that you know of BDD is rspec, that's an easy misunderstanding > to have. I'd give Dan North's blog a read to help understand the > greater context. In the end it's about language and collaboration > between technical people and non-technical people. Yes, I just started reading his blog. I like his perspective on communication with the client and his simple specification process in his Introducing BDD article. Also, even as a granular, developer practice (absent the wider team > piece), rspec offers clarity in the way you organize your specs (by > context). It offers clarity in the expression of expectations > (actual.should == expected vs assert_equal(:am_i_expected_or_actual, > :am_i_actual_or_expected). > > > There are also a number of people who do see benefits to using rspec and > are > > excited by it, so I do have "allies". :) > > > > I'm particularly interested in showing: > > > > How BDD is really good TDD without sounding religious > > How rspec encourages developers to create better "tests" than > > Focus on your own experience. Do you believe that BDD changes the > conversation? Do you believe that you write better tests (if you MUST > call them that) I like specs and behaviour myself. :) because rspec encourages you to do so? If so, then try > to tap that. How are they better? Are you writing better code? Are > your designs simpler? Are they easier to change later? Etc, etc. If > the answer to these things is no, then you probably shouldn't be > evangelizing it. That would be dishonest. Just tell people about it > and what your experience is either way (the things you like, the > things you don't). 2 cents. These are all good that set the appropriate tone for the brown bag. Theres alot to think about here. Thank you. Also, my coworker, Benny Sadeh advised me to treat the Brown Bag as a discussion and exploration of what can be learned from BDD and rspec. The group will probably be fairly sizable (mid to high teens) but that should be managable. > Test::UnitThank you, > > Brian Takita > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061120/2608cc2a/attachment-0001.html From brian.takita at gmail.com Tue Nov 21 01:39:17 2006 From: brian.takita at gmail.com (Brian Takita) Date: Mon, 20 Nov 2006 22:39:17 -0800 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: <6E4B61B7-C59B-4CC5-817D-AF5619AB83F4@gmail.com> References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> <6E4B61B7-C59B-4CC5-817D-AF5619AB83F4@gmail.com> Message-ID: <1d7ddd110611202239g176a905eidb855b314e3bf98c@mail.gmail.com> On 11/20/06, Brandon Keepers wrote: > > One of the things that has sold me on rspec--besides the fact that it > encourages better tests--is the ability to print out the specs from > your app. For example, the following are the start of some specs for > an ecommerce app I am working on. I can take my tests (specs derived > from user stories) and generate documentation that I can hand > directly to the customer, and it makes perfect sense to them. There > is no question as to what the app does and whether or not the specs > are up to date. That alone is worth it's weight in gold. Agreed. This is a sweet feature. A user > - can purchase items > - should have many orders > > A user purchasing items > - should create an order > - should add to the user's orders > - should create line items > - should set line item amount to the item's price > - should set line item amount to 0 if item does not have a price > > An order > - should have line_items > - should have an invoice > - should be invalid without an amount > > An invoice > - should have many orders > - should be invalid without an amount > - should have many payments > - should belong to a user > > Paying an invoice > - should create a payment > - should set payment amount equal to invoice amount > - should set payment confirmation number > > Calling invoice.pay with an invalid credit card > - should raise AuthorizationError > > A payment > - should belong to an invoice > - should be invalid without an amount > > Brandon > > On Nov 20, 2006, at 9:07 PM, Brian Takita wrote: > > > Hello, > > > > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for > > my company (Pivotal Computer Systems, http://www.pivotalsf.com). I > > did see Dave Astel's talk as well as several of my coworkers. > > The developers at my workplace are experienced Agile developers. > > > > What would be some good things to focus on for this brown bag? > > Are there slides to presentations that would be useful? > > Any resistance/skepticism, and how to best address these concerns? > > > > I'm kindof nervous because there is some skepticism toward rspec > > and BDD. > > > > Mainly: > > Test::Unit already does that, so why do we need rspec? > > It's not production ready. (Stack traces are too cluttered for > > RspecOnRails; although this opinion was based on version 0.6) > > New people will be confused seeing rspec code (although this is > > solved by more education, usage, encapsulation, etc.) > > BDD is TDD using "should" instead of "assert" > > There are also a number of people who do see benefits to using > > rspec and are excited by it, so I do have "allies". :) > > > > I'm particularly interested in showing: > > How BDD is really good TDD without sounding religious > > How rspec encourages developers to create better "tests" than > > Test::Unit > > Thank you, > > Brian Takita > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061120/52ec1174/attachment.html From noreply at rubyforge.org Tue Nov 21 02:55:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Nov 2006 02:55:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6798 ] ensure two ':' in the first backtrace line for Emacs's 'next-error' command Message-ID: <20061121075512.B91655240A03@rubyforge.org> Patches item #6798, was opened at 2006-11-21 16:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6798&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kouhei Sutou (kou) Assigned to: Nobody (None) Summary: ensure two ':' in the first backtrace line for Emacs's 'next-error' command Initial Comment: I'm running RSpec on Emacs's compilation mode. In compilation mode, we can jump to next error by C-x `. And compilation mode recognize error location by the following format: PATH:LINE_NO:[OPTIONAL_MESSAGE] RSpec output backtrace like the following format: PATH:LINE_NO[: OPTIONAL_MESSAGE] We can jump to an error location when there is ':' after LINE_NO but RSpec doesn't output ':' after LINE_NO anytime. Could you output ':' after LINE_NO to use C-x `? But I think RSpec doesn't need to output the ':' anytime. RSpec needs to output the ':' only when the first line in backtrace. Because we are interested in the location where the error is occurred but aren't interested in other location in backtrace. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6798&group_id=797 From noreply at rubyforge.org Tue Nov 21 04:09:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Nov 2006 04:09:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6780 ] routing() was failing...fix included Message-ID: <20061121090905.BB6E35240A52@rubyforge.org> Bugs item #6780, was opened at 2006-11-19 14:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Gustav Paul (gustavpaul) Assigned to: David Chelimsky (dchelimsky) Summary: routing() was failing...fix included Initial Comment: Hey I have the following route in my config/routes.rb: map.connect 'login', :controller => 'member', :action => 'login' my spec looks as follows #no def setup or anything similar... specify "/member/login should route to /login" do routing(:controller => 'member', :action => 'login').should_eql "/login" end Was failing, reporting inequality of 47 and '/login' "/login"[0] happened to be char code 47 I've got the rails plugin installed as /vendor/plugins/rspec_on_rails In /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb line #131 Was: ActionController::Routing::Routes.generate(options)[0] changed to ActionController::Routing::Routes.generate(options) Working perfectly now... Might have introduced other bugs, but I though I'd let you guys know... Cheery-o Gustav Paul gustav at rails.co.za ---------------------------------------------------------------------- Comment By: Marcus Roberts (marcusr) Date: 2006-11-21 09:09 Message: I see the same problem. I'm running on edge rails (REVISION_5587) using RSPec gem 0.7.2 and Rspec Rails plugin checked out with ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec. Removing the [0] from the same line (line number 142 in my version) of /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb removes the error of "47 should == "/customers" in my own test Marcus ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 15:04 Message: He's probably on edge rails. I think edge rails and 1.1.6 rails behave differently. In edge rails the [0] must go away. Maybe we need to do different things based on RAILS_VERSION or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-20 03:36 Message: Gustav - I added a spec for this and it passed right away. It's committed in revision (1126). What version of RSpec were you using when this happened? Trunk revision? Rails version? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 From brian.takita at gmail.com Tue Nov 21 04:52:18 2006 From: brian.takita at gmail.com (Brian Takita) Date: Tue, 21 Nov 2006 01:52:18 -0800 Subject: [rspec-devel] Specification Reuse to avoid Combinatorial Explosions Message-ID: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com> Hello, While reading Dan North's BDD tutorial , I tried to implement his ATM example as spec stubs. When I first implemented it creating a context for each of his scenarios, I noticed that there is duplication and a combinatorial explosion of the specs. I attached the full files to this email. For brevity, I will use scenario 1 in the body of this email. For the purpose of this exercise, one should imagine that each specification is at least 5 lines. Here is how I implemented scenario 1: context %{A Withdrawal where an Account is in credit AND the card is valid AND the dispenser contains cash AND the customer requests cash} do specify "should debit the account" do end specify "should dispense cash" do end specify "should return the card" do end end That got me experimenting on reusing specifications by using a module to create the specs. This is in customer_withdraws_cash_spec.rb: module CustomerWithdrawsCashSpec def should_debit_the_account specify "should debit the account" do end end ... end ... context %{A Withdrawal where an Account is in credit AND the card is valid AND the dispenser contains cash AND the customer requests cash} do extend CustomerWithdrawsCashSpec should_debit_the_account should_dispense_cash should_return_the_card end This is currently possible with rspec 0.7.2. Whats interesting about putting all of the specifications into a module is that you can reduce the context to a few lines. This makes each context (scenario readable) making it more feasible to have multiple contexts in a single file such as this group of scenarios represented as contexts. I also played with a more DSL-like syntax for this, which does not work for rspec 0.7.2. This is in customer_withdraws_cash_alternative_spec.rb:: CustomerWithdrawsCashSpec = context_module do specify "should debit the account" do end ... end context %{A Withdrawal where an Account is in credit AND the card is valid AND the dispenser contains cash AND the customer requests cash} do extend CustomerWithdrawsCashSpec specify "should debit the account" specify "should dispense cash" specify "should return the card" end As well as: context %{A Withdrawal where an Account is in credit AND the card is valid AND the dispenser contains cash AND the customer requests cash} do specify "should debit the account", CustomerWithdrawsCashSpec specify "should dispense cash", CustomerWithdrawsCashSpec specify "should return the card", CustomerWithdrawsCashSpec end Or just keep the underscore syntax: context %{A Withdrawal where an Account is in credit AND the card is valid AND the dispenser contains cash AND the customer requests cash} do extend CustomerWithdrawsCashSpec should_debit_the_account should_dispense_cash should_return_the_card end Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061121/64922509/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: customer_withdraws_cash_spec.rb Type: application/x-ruby Size: 2383 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061121/64922509/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: customer_withdraws_cash_alternative_spec.rb Type: application/x-ruby Size: 2300 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061121/64922509/attachment-0003.bin From noreply at rubyforge.org Tue Nov 21 04:52:34 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Nov 2006 04:52:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6780 ] routing() was failing...fix included Message-ID: <20061121095234.C2D225240A5D@rubyforge.org> Bugs item #6780, was opened at 2006-11-19 16:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Gustav Paul (gustavpaul) Assigned to: David Chelimsky (dchelimsky) Summary: routing() was failing...fix included Initial Comment: Hey I have the following route in my config/routes.rb: map.connect 'login', :controller => 'member', :action => 'login' my spec looks as follows #no def setup or anything similar... specify "/member/login should route to /login" do routing(:controller => 'member', :action => 'login').should_eql "/login" end Was failing, reporting inequality of 47 and '/login' "/login"[0] happened to be char code 47 I've got the rails plugin installed as /vendor/plugins/rspec_on_rails In /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb line #131 Was: ActionController::Routing::Routes.generate(options)[0] changed to ActionController::Routing::Routes.generate(options) Working perfectly now... Might have introduced other bugs, but I though I'd let you guys know... Cheery-o Gustav Paul gustav at rails.co.za ---------------------------------------------------------------------- >Comment By: Gustav Paul (gustavpaul) Date: 2006-11-21 11:52 Message: First of all... I'm terribly sorry that I took so long to respond! Second... Yup, I'm on edge rails, I followed these guidelines if that's any help :] http://www.flpr.org/2006/11/15/edge-rspec-on-rails With only minor deviations... I ran svn exported rspec and the rspec_on_rails plugin instead of checking out. EDGE REVISION 5526 (according to /vendor/rails/) Thanks everyone, Gustav ---------------------------------------------------------------------- Comment By: Marcus Roberts (marcusr) Date: 2006-11-21 11:09 Message: I see the same problem. I'm running on edge rails (REVISION_5587) using RSPec gem 0.7.2 and Rspec Rails plugin checked out with ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec. Removing the [0] from the same line (line number 142 in my version) of /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb removes the error of "47 should == "/customers" in my own test Marcus ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 17:04 Message: He's probably on edge rails. I think edge rails and 1.1.6 rails behave differently. In edge rails the [0] must go away. Maybe we need to do different things based on RAILS_VERSION or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-20 05:36 Message: Gustav - I added a spec for this and it passed right away. It's committed in revision (1126). What version of RSpec were you using when this happened? Trunk revision? Rails version? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 From dchelimsky at gmail.com Tue Nov 21 08:00:27 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 21 Nov 2006 07:00:27 -0600 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: <1d7ddd110611202238y77c6af08j71b27cf9150b2ba@mail.gmail.com> References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> <57c63afe0611202129v74b14feancd9aefaa7bc33b38@mail.gmail.com> <1d7ddd110611202238y77c6af08j71b27cf9150b2ba@mail.gmail.com> Message-ID: <57c63afe0611210500g110561cbk7f4da9a687b2014b@mail.gmail.com> On 11/21/06, Brian Takita wrote: > Also, my coworker, Benny Sadeh advised me to treat the Brown Bag as a > discussion and exploration of what can be learned from BDD and rspec. Yes, yes, yes, yes! That is fantastic advice. Please report back to let us know how it all went. Good and/or bad. Good luck! David From dchelimsky at gmail.com Tue Nov 21 08:48:17 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 21 Nov 2006 07:48:17 -0600 Subject: [rspec-devel] Specification Reuse to avoid Combinatorial Explosions In-Reply-To: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com> References: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com> Message-ID: <57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com> On 11/21/06, Brian Takita wrote: > Hello, > > While reading Dan North's BDD tutorial, I tried to implement his ATM example > as spec stubs. > When I first implemented it creating a context for each of his scenarios, I > noticed that there is duplication and a combinatorial explosion of the > specs. > > I attached the full files to this email. For brevity, I will use scenario 1 > in the body of this email. For the purpose of this exercise, one should > imagine that each specification is at least 5 lines. > > Here is how I implemented scenario 1: > > context %{A Withdrawal where an Account is in credit > AND the card is valid > AND the dispenser contains cash > AND the customer requests cash} do > > specify "should debit the account" do > end > specify "should dispense cash" do > end > specify "should return the card" do > end > end > > That got me experimenting on reusing specifications by using a module to > create the specs. This is in > customer_withdraws_cash_spec.rb: > > module CustomerWithdrawsCashSpec > def should_debit_the_account > specify "should debit the account" do > end > end > ... > end > ... > context %{A Withdrawal where an Account is in credit > AND the card is valid > AND the dispenser contains cash > AND the customer requests cash} do > > extend CustomerWithdrawsCashSpec > should_debit_the_account > should_dispense_cash > should_return_the_card > end > > This is currently possible with rspec 0.7.2. > Whats interesting about putting all of the specifications into a module is > that you can reduce the context to a few lines. > This makes each context (scenario readable) making it more feasible to have > multiple contexts in a single file such as this group of scenarios > represented as contexts. > > I also played with a more DSL-like syntax for this, which does not work for > rspec 0.7.2. This is in > customer_withdraws_cash_alternative_spec.rb:: > > CustomerWithdrawsCashSpec = context_module do > specify "should debit the account" do > end > ... > end > > context %{A Withdrawal where an Account is in credit > AND the card is valid > AND the dispenser contains cash > AND the customer requests cash} do > > extend CustomerWithdrawsCashSpec > specify "should debit the account" > specify "should dispense cash" > specify "should return the card" > end > > As well as: > > context %{A Withdrawal where an Account is in credit > AND the card is valid > AND the dispenser contains cash > AND the customer requests cash} do > > specify "should debit the account", CustomerWithdrawsCashSpec > specify "should dispense cash", CustomerWithdrawsCashSpec > specify "should return the card", CustomerWithdrawsCashSpec > end > > Or just keep the underscore syntax: > > context %{A Withdrawal where an Account is in credit > AND the card is valid > AND the dispenser contains cash > AND the customer requests cash} do > > extend CustomerWithdrawsCashSpec > should_debit_the_account > should_dispense_cash > should_return_the_card > end Interesting ideas. If we pursue this, I'd like to find an approach that aligns w/ RSpecs current lack of constructs like classes and modules. So rather than CustomerWithdrawsCashSpec = context_module do ... context "..." do extend CustomerWithdrawsCashSpec I'd like something like context_module :customer_withdraws_cash do context "...", :customer_withdraws_cash do That's not exactly right, but you get the idea. Also - I think it would be really helpful for this discussion if you *would* post the full specs so we can see what this stuff really looks like in context. Thanks Brian. David From noreply at rubyforge.org Tue Nov 21 14:27:36 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Nov 2006 14:27:36 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6807 ] port assert_select Message-ID: <20061121192736.64CFB5240C20@rubyforge.org> Feature Requests item #6807, was opened at 2006-11-21 19:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: port assert_select Initial Comment: Add an rspec implementation of assert_select. Need to decide whether to just duplicate existing API (using repsonse.should_have?????) or actually devise a more integrated API like this: repsonse.should_include(:form).with(:action => "blah") or response.should_include(:form).with do |form| form.should_include(:input).with(:name => 'age', :type => 'text') end or some such. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 From bkeepers at gmail.com Tue Nov 21 15:51:56 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Tue, 21 Nov 2006 15:51:56 -0500 Subject: [rspec-devel] Specification Reuse to avoid Combinatorial Explosions In-Reply-To: <57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com> References: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com> <57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com> Message-ID: <2A0981DC-A32F-4BCB-8141-22B44AB5869F@gmail.com> One of the things I've often wished for is nested contexts. This could help eliminate some duplication. context "A Widthdrawal" do context "where an Account is in credit" do context "and the card is valid" context "and the dispenser contains cash" do specify "should debit the account" do end specify "should dispense cash" do end specify "should return the card" do end end context "and the dispenser does not contain cash" do specify "should inform the user" do end end end end end Brandon On Nov 21, 2006, at 8:48 AM, David Chelimsky wrote: > On 11/21/06, Brian Takita wrote: >> Hello, >> >> While reading Dan North's BDD tutorial, I tried to implement his >> ATM example >> as spec stubs. >> When I first implemented it creating a context for each of his >> scenarios, I >> noticed that there is duplication and a combinatorial explosion of >> the >> specs. >> >> I attached the full files to this email. For brevity, I will use >> scenario 1 >> in the body of this email. For the purpose of this exercise, one >> should >> imagine that each specification is at least 5 lines. >> >> Here is how I implemented scenario 1: >> >> context %{A Withdrawal where an Account is in credit >> AND the card is valid >> AND the dispenser contains cash >> AND the customer requests cash} do >> >> specify "should debit the account" do >> end >> specify "should dispense cash" do >> end >> specify "should return the card" do >> end >> end >> >> That got me experimenting on reusing specifications by using a >> module to >> create the specs. This is in >> customer_withdraws_cash_spec.rb: >> >> module CustomerWithdrawsCashSpec >> def should_debit_the_account >> specify "should debit the account" do >> end >> end >> ... >> end >> ... >> context %{A Withdrawal where an Account is in credit >> AND the card is valid >> AND the dispenser contains cash >> AND the customer requests cash} do >> >> extend CustomerWithdrawsCashSpec >> should_debit_the_account >> should_dispense_cash >> should_return_the_card >> end >> >> This is currently possible with rspec 0.7.2. >> Whats interesting about putting all of the specifications into a >> module is >> that you can reduce the context to a few lines. >> This makes each context (scenario readable) making it more >> feasible to have >> multiple contexts in a single file such as this group of scenarios >> represented as contexts. >> >> I also played with a more DSL-like syntax for this, which does not >> work for >> rspec 0.7.2. This is in >> customer_withdraws_cash_alternative_spec.rb:: >> >> CustomerWithdrawsCashSpec = context_module do >> specify "should debit the account" do >> end >> ... >> end >> >> context %{A Withdrawal where an Account is in credit >> AND the card is valid >> AND the dispenser contains cash >> AND the customer requests cash} do >> >> extend CustomerWithdrawsCashSpec >> specify "should debit the account" >> specify "should dispense cash" >> specify "should return the card" >> end >> >> As well as: >> >> context %{A Withdrawal where an Account is in credit >> AND the card is valid >> AND the dispenser contains cash >> AND the customer requests cash} do >> >> specify "should debit the account", CustomerWithdrawsCashSpec >> specify "should dispense cash", CustomerWithdrawsCashSpec >> specify "should return the card", CustomerWithdrawsCashSpec >> end >> >> Or just keep the underscore syntax: >> >> context %{A Withdrawal where an Account is in credit >> AND the card is valid >> AND the dispenser contains cash >> AND the customer requests cash} do >> >> extend CustomerWithdrawsCashSpec >> should_debit_the_account >> should_dispense_cash >> should_return_the_card >> end > > Interesting ideas. If we pursue this, I'd like to find an approach > that aligns w/ RSpecs current lack of constructs like classes and > modules. So rather than > > CustomerWithdrawsCashSpec = context_module do ... > > context "..." do > extend CustomerWithdrawsCashSpec > > I'd like something like > > context_module :customer_withdraws_cash do > > context "...", :customer_withdraws_cash do > > That's not exactly right, but you get the idea. > > Also - I think it would be really helpful for this discussion if you > *would* post the full specs so we can see what this stuff really looks > like in context. > > Thanks Brian. > > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Tue Nov 21 16:08:22 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 21 Nov 2006 15:08:22 -0600 Subject: [rspec-devel] Specification Reuse to avoid Combinatorial Explosions In-Reply-To: <2A0981DC-A32F-4BCB-8141-22B44AB5869F@gmail.com> References: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com> <57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com> <2A0981DC-A32F-4BCB-8141-22B44AB5869F@gmail.com> Message-ID: <57c63afe0611211308w7f8866a1ydebfe3019e928000@mail.gmail.com> On 11/21/06, Brandon Keepers wrote: > One of the things I've often wished for is nested contexts. This > could help eliminate some duplication. We've been through this a couple of times. Give this one a read please: http://rubyforge.org/pipermail/rspec-devel/2006-June/000175.html From dchelimsky at gmail.com Tue Nov 21 16:12:23 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 21 Nov 2006 15:12:23 -0600 Subject: [rspec-devel] Specification Reuse to avoid Combinatorial Explosions In-Reply-To: <57c63afe0611211308w7f8866a1ydebfe3019e928000@mail.gmail.com> References: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com> <57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com> <2A0981DC-A32F-4BCB-8141-22B44AB5869F@gmail.com> <57c63afe0611211308w7f8866a1ydebfe3019e928000@mail.gmail.com> Message-ID: <57c63afe0611211312k1bc4c8fcy29556306fd3cafcd@mail.gmail.com> On 11/21/06, David Chelimsky wrote: > On 11/21/06, Brandon Keepers wrote: > > One of the things I've often wished for is nested contexts. This > > could help eliminate some duplication. > > We've been through this a couple of times. Give this one a read please: > > http://rubyforge.org/pipermail/rspec-devel/2006-June/000175.html Specifically this reply from me: http://rubyforge.org/pipermail/rspec-devel/2006-June/000201.html From noreply at rubyforge.org Tue Nov 21 17:43:09 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 21 Nov 2006 17:43:09 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6807 ] port assert_select Message-ID: <20061121224309.5E18D5240F1E@rubyforge.org> Feature Requests item #6807, was opened at 2006-11-21 14:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: port assert_select Initial Comment: Add an rspec implementation of assert_select. Need to decide whether to just duplicate existing API (using repsonse.should_have?????) or actually devise a more integrated API like this: repsonse.should_include(:form).with(:action => "blah") or response.should_include(:form).with do |form| form.should_include(:input).with(:name => 'age', :type => 'text') end or some such. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-21 17:43 Message: I like the: repsonse.should_include(:form).with(:action => "blah") version, myself. The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If someone writes the specs for it, I will code it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 From aslak.hellesoy at gmail.com Tue Nov 21 18:46:25 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 22 Nov 2006 00:46:25 +0100 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> Message-ID: <8d961d900611211546o2060fc5cgee9d8990755b1a8f@mail.gmail.com> On 11/21/06, Brian Takita wrote: > Hello, > > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my > company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see Dave > Astel's talk as well as several of my coworkers. > The developers at my workplace are experienced Agile developers. > > What would be some good things to focus on for this brown bag? > Are there slides to presentations that would be useful? > Any resistance/skepticism, and how to best address these concerns? > I have had success with an explanation of the TDD journey as described here: http://www.behaviour-driven.org/TDDAdoptionProfile I usually present it with takahashi-style slides (http://tinyurl.com/o6psh) with the following words (one on each slide): * tests * confidence * before * documentation * discovery * behaviour * mocking > I'm kindof nervous because there is some skepticism toward rspec and BDD. > > Mainly: > > Test::Unit already does that, so why do we need rspec? > It's not production ready. (Stack traces are too cluttered for RspecOnRails; > although this opinion was based on version 0.6) > New people will be confused seeing rspec code (although this is solved by > more education, usage, encapsulation, etc.) > BDD is TDD using "should" instead of "assert" > There are also a number of people who do see benefits to using rspec and are > excited by it, so I do have "allies". :) > > I'm particularly interested in showing: > > How BDD is really good TDD without sounding religious > How rspec encourages developers to create better "tests" than > Test::UnitThank you, > Brian Takita > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From brian.takita at gmail.com Tue Nov 21 20:35:06 2006 From: brian.takita at gmail.com (Brian Takita) Date: Tue, 21 Nov 2006 17:35:06 -0800 Subject: [rspec-devel] Specification Reuse to avoid Combinatorial Explosions In-Reply-To: <57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com> References: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com> <57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com> Message-ID: <1d7ddd110611211735m3620744ic67eafab5b20ab26@mail.gmail.com> On 11/21/06, David Chelimsky wrote: > > On 11/21/06, Brian Takita wrote: > > Hello, > > > > While reading Dan North's BDD tutorial, I tried to implement his ATM > example > > as spec stubs. > > When I first implemented it creating a context for each of his > scenarios, I > > noticed that there is duplication and a combinatorial explosion of the > > specs. > > > > I attached the full files to this email. For brevity, I will use > scenario 1 > > in the body of this email. For the purpose of this exercise, one should > > imagine that each specification is at least 5 lines. > > > > Here is how I implemented scenario 1: > > > > context %{A Withdrawal where an Account is in credit > > AND the card is valid > > AND the dispenser contains cash > > AND the customer requests cash} do > > > > specify "should debit the account" do > > end > > specify "should dispense cash" do > > end > > specify "should return the card" do > > end > > end > > > > That got me experimenting on reusing specifications by using a module to > > > create the specs. This is in > > customer_withdraws_cash_spec.rb: > > > > module CustomerWithdrawsCashSpec > > def should_debit_the_account > > specify "should debit the account" do > > end > > end > > ... > > end > > ... > > context %{A Withdrawal where an Account is in credit > > AND the card is valid > > AND the dispenser contains cash > > AND the customer requests cash} do > > > > extend CustomerWithdrawsCashSpec > > should_debit_the_account > > should_dispense_cash > > should_return_the_card > > end > > > > This is currently possible with rspec 0.7.2 . > > Whats interesting about putting all of the specifications into a module > is > > that you can reduce the context to a few lines. > > This makes each context (scenario readable) making it more feasible to > have > > multiple contexts in a single file such as this group of scenarios > > represented as contexts. > > > > I also played with a more DSL-like syntax for this, which does not work > for > > rspec 0.7.2. This is in > > customer_withdraws_cash_alternative_spec.rb:: > > > > CustomerWithdrawsCashSpec = context_module do > > specify "should debit the account" do > > end > > ... > > end > > > > context %{A Withdrawal where an Account is in credit > > AND the card is valid > > AND the dispenser contains cash > > AND the customer requests cash} do > > > > extend CustomerWithdrawsCashSpec > > specify "should debit the account" > > specify "should dispense cash" > > specify "should return the card" > > end > > > > As well as: > > > > context %{A Withdrawal where an Account is in credit > > AND the card is valid > > AND the dispenser contains cash > > AND the customer requests cash} do > > > > specify "should debit the account", CustomerWithdrawsCashSpec > > specify "should dispense cash", CustomerWithdrawsCashSpec > > specify "should return the card", CustomerWithdrawsCashSpec > > end > > > > Or just keep the underscore syntax: > > > > context %{A Withdrawal where an Account is in credit > > AND the card is valid > > AND the dispenser contains cash > > AND the customer requests cash} do > > > > extend CustomerWithdrawsCashSpec > > should_debit_the_account > > should_dispense_cash > > should_return_the_card > > end > > Interesting ideas. If we pursue this, I'd like to find an approach > that aligns w/ RSpecs current lack of constructs like classes and > modules. So rather than > > CustomerWithdrawsCashSpec = context_module do ... > > context "..." do > extend CustomerWithdrawsCashSpec > > I'd like something like > > context_module :customer_withdraws_cash do > > context "...", :customer_withdraws_cash do > > That's not exactly right, but you get the idea. > > Also - I think it would be really helpful for this discussion if you > *would* post the full specs so we can see what this stuff really looks > like in context. I sent the files as attachments. I guess they got rejected. Here is the file that works now: require "rubygems" require "spec" ARGV << "--format" ARGV << "specdoc" =begin Title: Customer withdraws cash As a customer, I want to withdraw cash from an ATM, so that I don't have to wait in line at the bank. =end module CustomerWithdrawsCashSpec def should_debit_the_account specify "should debit the account" do end end def should_display_a_rejection_message specify "should display a rejection message" do end end def should_display_an_error_message specify "should display an error message" do end end def should_dispense_cash specify "should dispense cash" do end end def should_not_dispense_cash specify "should not dispense cash" do end end def should_return_the_card specify "should return the card" do end end def should_not_return_the_card specify "should not return the card" do end end end context %{A Withdrawal where an Account is in credit AND the card is valid AND the dispenser contains cash AND the customer requests cash} do extend CustomerWithdrawsCashSpec should_debit_the_account should_dispense_cash should_return_the_card end context %{A Withdrawal where an Account is in credit AND the card is NOT valid AND NOT stolen AND the dispenser contains cash AND the customer requests cash} do extend CustomerWithdrawsCashSpec should_display_a_rejection_message should_not_dispense_cash should_return_the_card end context %{A Withdrawal where an Account is in credit AND the card is NOT valid AND stolen AND the dispenser contains cash AND the customer requests cash} do extend CustomerWithdrawsCashSpec should_display_a_rejection_message should_not_dispense_cash should_not_return_the_card end context %{A Withdrawal where an Account is in credit AND the card is valid AND the dispenser DOES NOT contain cash AND the customer requests cash} do extend CustomerWithdrawsCashSpec should_display_an_error_message should_not_dispense_cash should_return_the_card end context %{A Withdrawal where an Account is overdrawn AND the card is valid AND the customer requests cash} do extend CustomerWithdrawsCashSpec should_display_a_rejection_message should_not_dispense_cash should_return_the_card end And here is the alternative source: require "rubygems" require "spec" ARGV << "--format" ARGV << "specdoc" =begin Title: Customer withdraws cash As a customer, I want to withdraw cash from an ATM, so that I don't have to wait in line at the bank. =end CustomerWithdrawsCashSpec = context_module do specify "should debit the account" do end specify "should display a rejection message" do end specify "should display an error message" do end specify "should dispense cash" do end specify "should not dispense cash" do end specify "should return the card" do end specify "should not return the card" do end end context %{A Withdrawal where an Account is in credit AND the card is valid AND the dispenser contains cash AND the customer requests cash} do extend CustomerWithdrawsCashSpec specify "should debit the account" specify "should dispense cash" specify "should return the card" end context %{A Withdrawal where an Account is in credit AND the card is NOT valid AND NOT stolen AND the dispenser contains cash AND the customer requests cash} do specify "should display a rejection message", CustomerWithdrawsCashSpec specify "should not dispense cash", CustomerWithdrawsCashSpec specify "should return the card", CustomerWithdrawsCashSpec end context %{A Withdrawal where an Account is in credit AND the card is NOT valid AND stolen AND the dispenser contains cash AND the customer requests cash} do extend customer_withdraws_cash specify "should display a rejection message" specify "should not dispense cash" specify "should not return the card" end context %{A Withdrawal where an Account is in credit AND the card is valid AND the dispenser DOES NOT contain cash AND the customer requests cash} do specify "should display an error message", customer_withdraws_cash specify "should not dispense cash", customer_withdraws_cash specify "should return the card", customer_withdraws_cash end context %{A Withdrawal where an Account is overdrawn AND the card is valid AND the customer requests cash} do extend CustomerWithdrawsCashSpec should_display_a_rejection_message should_not_dispense_cash should_return_the_card end Thanks Brian. > > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061121/199e7d57/attachment-0001.html From noreply at rubyforge.org Wed Nov 22 04:48:15 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 22 Nov 2006 04:48:15 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6807 ] port assert_select Message-ID: <20061122094815.9B5185240D54@rubyforge.org> Feature Requests item #6807, was opened at 2006-11-21 19:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: port assert_select Initial Comment: Add an rspec implementation of assert_select. Need to decide whether to just duplicate existing API (using repsonse.should_have?????) or actually devise a more integrated API like this: repsonse.should_include(:form).with(:action => "blah") or response.should_include(:form).with do |form| form.should_include(:input).with(:name => 'age', :type => 'text') end or some such. ---------------------------------------------------------------------- Comment By: Josh Chisholm (joshchisholm) Date: 2006-11-22 09:48 Message: I implemented a basic response.should_select by mixing in scrAPI. Haven't brought it up to date with rspec 0.72 yet, but I will if someone advises the best way to do so (assuming we don't want a scrAPI dependency in rspec core? - a plugin??). > The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If I understand correcly the second example implies the form has a child (somewhere unspecified) with certain specified attributes. I don't find this too detailed and if I remember correctly this can be done with a single selector: response.should_select "form>input[name=age][type=text]" This syntax is all I have needed so far. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-21 22:43 Message: I like the: repsonse.should_include(:form).with(:action => "blah") version, myself. The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If someone writes the specs for it, I will code it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 From brian.takita at gmail.com Wed Nov 22 05:19:28 2006 From: brian.takita at gmail.com (Brian Takita) Date: Wed, 22 Nov 2006 02:19:28 -0800 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: <8d961d900611211546o2060fc5cgee9d8990755b1a8f@mail.gmail.com> References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> <8d961d900611211546o2060fc5cgee9d8990755b1a8f@mail.gmail.com> Message-ID: <1d7ddd110611220219mfa0d989ga7ce484b219d7119@mail.gmail.com> On 11/21/06, aslak hellesoy wrote: > > On 11/21/06, Brian Takita wrote: > > Hello, > > > > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my > > company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see > Dave > > Astel's talk as well as several of my coworkers. > > The developers at my workplace are experienced Agile developers. > > > > What would be some good things to focus on for this brown bag? > > Are there slides to presentations that would be useful? > > Any resistance/skepticism, and how to best address these concerns? > > > > I have had success with an explanation of the TDD journey as described > here: > http://www.behaviour-driven.org/TDDAdoptionProfile > > I usually present it with takahashi-style slides > (http://tinyurl.com/o6psh) with the following words (one on each > slide): > * tests > * confidence > * before > * documentation > * discovery > * behaviour > * mocking This looks good. I think I'll start with this and then move to the demo. Dan North's ATM example is a juicy example for using rspec to drive domain concepts. The specdocs will come in handy here. Then I'll do a short rspec on rails demo showing the model, control, view, and helper specs. Which should leave plenty of time for discussion and further examples. I'll also invite discussion during the "presentation". Everyone, thanks for your help. Brian > I'm kindof nervous because there is some skepticism toward rspec and BDD. > > > > Mainly: > > > > Test::Unit already does that, so why do we need rspec? > > It's not production ready. (Stack traces are too cluttered for > RspecOnRails; > > although this opinion was based on version 0.6) > > New people will be confused seeing rspec code (although this is solved > by > > more education, usage, encapsulation, etc.) > > BDD is TDD using "should" instead of "assert" > > There are also a number of people who do see benefits to using rspec and > are > > excited by it, so I do have "allies". :) > > > > I'm particularly interested in showing: > > > > How BDD is really good TDD without sounding religious > > How rspec encourages developers to create better "tests" than > > Test::UnitThank you, > > Brian Takita > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061122/0bdc0d0b/attachment.html From noreply at rubyforge.org Wed Nov 22 05:40:54 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 22 Nov 2006 05:40:54 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6674 ] rspec_on_rails fails on @session deprecation warning? Message-ID: <20061122104055.6AEFB5240DDE@rubyforge.org> Bugs item #6674, was opened at 2006-11-14 18:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6674&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Steve Ross (sxross) Assigned to: Nobody (None) Summary: rspec_on_rails fails on @session deprecation warning? Initial Comment: rSpec 0.7.2 and rspec_on_rails 0.7.2 on Edge Rails (5473). I'm not certain that the deprecation warnings are causing this, but that's how it looks to me. By the way, the line 'puts self.class' outputs 'F'. Is this expected? Simple view test: require File.dirname(__FILE__) + '/../spec_helper' context "/member/index" do setup do @member = mock("member") @content_for_title = 'sign up for mailing list' @member.should_receive(:member) assigns[:member] = [@member] end specify "should show signup page" do puts self.class render '/member/index' response.should_have_tag 'div', attributes =>{:id => "intro"} end end Results: 1) RuntimeError in '/member/index should show signup page' Deprecating @session, but it's already set to #{}}>! Use the session= writer method instead of setting @session directly. /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1049:in `assign_deprecated_shortcuts' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1044:in `assign_deprecated_shortcuts' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1035:in `assign_shortcuts_without_flash' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/flash.rb:140:in `assign_shortcuts' Finished in 0.063727 seconds 1 specification, 1 failure rake aborted! Command failed with status (1): [/usr/local/bin/ruby -I"/usr/local/lib/ruby...] ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-22 10:40 Message: Not so easy. Zen is gone from trunk and the problem still exists on edge rails. It has to do with a change in Rails from using @session to @_session. Not sure what the best course is here. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 15:06 Message: This is ZenTest's fault. This will go away when we get rid of ZenTest. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-19 20:30 Message: Moving this to bugs ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6674&group_id=797 From noreply at rubyforge.org Wed Nov 22 07:28:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 22 Nov 2006 07:28:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6071 ] script/rails_spec causes MissingSourceFile error Message-ID: <20061122122826.85ABB5240EFC@rubyforge.org> Bugs item #6071, was opened at 2006-10-09 10:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6071&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: alan maybourne (nothingmuch) Assigned to: Nobody (None) Summary: script/rails_spec causes MissingSourceFile error Initial Comment: Windows XP Pro Ruby 1.8.4 Rails 1.1.6 rspec 0.6.4 I can successfully start the rspec server which gives the message "loading Rails Environment" followed by "Ready" but when I then try to use the rails_spec command here's what I get ----- C:\rails\morgan>ruby script/rails_spec reminder_spec.rb -f s c:/ruby/lib/ruby/1.8/drb/drb.rb:1090:in `method_missing': MissingSourceFile (DRb ::DRbUnknownError) from script/rails_spec:8 C:\rails\morgan> ----- running the spec on it's own using the spec command works fine ---------------------------------------------------------------------- >Comment By: alan maybourne (nothingmuch) Date: 2006-11-22 12:28 Message: works great as of 0.7.2 thanks for taking the time to follow up ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 04:17 Message: Alan - is this still an issue for you (as of 0.7.2 or trunk 1120)? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6071&group_id=797 From noreply at rubyforge.org Wed Nov 22 07:55:07 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 22 Nov 2006 07:55:07 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6071 ] script/rails_spec causes MissingSourceFile error Message-ID: <20061122125507.86CCA5240EC8@rubyforge.org> Bugs item #6071, was opened at 2006-10-09 10:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6071&group_id=797 >Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: alan maybourne (nothingmuch) Assigned to: Nobody (None) Summary: script/rails_spec causes MissingSourceFile error Initial Comment: Windows XP Pro Ruby 1.8.4 Rails 1.1.6 rspec 0.6.4 I can successfully start the rspec server which gives the message "loading Rails Environment" followed by "Ready" but when I then try to use the rails_spec command here's what I get ----- C:\rails\morgan>ruby script/rails_spec reminder_spec.rb -f s c:/ruby/lib/ruby/1.8/drb/drb.rb:1090:in `method_missing': MissingSourceFile (DRb ::DRbUnknownError) from script/rails_spec:8 C:\rails\morgan> ----- running the spec on it's own using the spec command works fine ---------------------------------------------------------------------- Comment By: alan maybourne (nothingmuch) Date: 2006-11-22 12:28 Message: works great as of 0.7.2 thanks for taking the time to follow up ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 04:17 Message: Alan - is this still an issue for you (as of 0.7.2 or trunk 1120)? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6071&group_id=797 From noreply at rubyforge.org Wed Nov 22 08:00:39 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 22 Nov 2006 08:00:39 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6807 ] port assert_select Message-ID: <20061122130040.095FA5240F0C@rubyforge.org> Feature Requests item #6807, was opened at 2006-11-21 19:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: port assert_select Initial Comment: Add an rspec implementation of assert_select. Need to decide whether to just duplicate existing API (using repsonse.should_have?????) or actually devise a more integrated API like this: repsonse.should_include(:form).with(:action => "blah") or response.should_include(:form).with do |form| form.should_include(:input).with(:name => 'age', :type => 'text') end or some such. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-22 13:00 Message: Josh - a plugin would be great. Could you use should_have instead of should_select (which doesn't really mean anything in this context): response.should_have "form>input[name=age][type=text]" I'm assuming you've got this implemented on ResponseBody, so there should be no conflict w/ Should#have. ---------------------------------------------------------------------- Comment By: Josh Chisholm (joshchisholm) Date: 2006-11-22 09:48 Message: I implemented a basic response.should_select by mixing in scrAPI. Haven't brought it up to date with rspec 0.72 yet, but I will if someone advises the best way to do so (assuming we don't want a scrAPI dependency in rspec core? - a plugin??). > The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If I understand correcly the second example implies the form has a child (somewhere unspecified) with certain specified attributes. I don't find this too detailed and if I remember correctly this can be done with a single selector: response.should_select "form>input[name=age][type=text]" This syntax is all I have needed so far. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-21 22:43 Message: I like the: repsonse.should_include(:form).with(:action => "blah") version, myself. The third seems to promote really detailed expectations about the HTML, and I think that way lies madness. If someone writes the specs for it, I will code it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6807&group_id=797 From noreply at rubyforge.org Wed Nov 22 08:01:22 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 22 Nov 2006 08:01:22 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6071 ] script/rails_spec causes MissingSourceFile error Message-ID: <20061122130122.C3D3E5240F0C@rubyforge.org> Bugs item #6071, was opened at 2006-10-09 10:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6071&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: alan maybourne (nothingmuch) Assigned to: Nobody (None) Summary: script/rails_spec causes MissingSourceFile error Initial Comment: Windows XP Pro Ruby 1.8.4 Rails 1.1.6 rspec 0.6.4 I can successfully start the rspec server which gives the message "loading Rails Environment" followed by "Ready" but when I then try to use the rails_spec command here's what I get ----- C:\rails\morgan>ruby script/rails_spec reminder_spec.rb -f s c:/ruby/lib/ruby/1.8/drb/drb.rb:1090:in `method_missing': MissingSourceFile (DRb ::DRbUnknownError) from script/rails_spec:8 C:\rails\morgan> ----- running the spec on it's own using the spec command works fine ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-22 13:01 Message: Thank you as well Alan. Cheers, David ---------------------------------------------------------------------- Comment By: alan maybourne (nothingmuch) Date: 2006-11-22 12:28 Message: works great as of 0.7.2 thanks for taking the time to follow up ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-17 04:17 Message: Alan - is this still an issue for you (as of 0.7.2 or trunk 1120)? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6071&group_id=797 From brian.takita at gmail.com Wed Nov 22 17:10:58 2006 From: brian.takita at gmail.com (Brian Takita) Date: Wed, 22 Nov 2006 14:10:58 -0800 Subject: [rspec-devel] Rspec Brown Bag In-Reply-To: <57c63afe0611210500g110561cbk7f4da9a687b2014b@mail.gmail.com> References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com> <57c63afe0611202129v74b14feancd9aefaa7bc33b38@mail.gmail.com> <1d7ddd110611202238y77c6af08j71b27cf9150b2ba@mail.gmail.com> <57c63afe0611210500g110561cbk7f4da9a687b2014b@mail.gmail.com> Message-ID: <1d7ddd110611221410ta147eb9u89ffa2f086294640@mail.gmail.com> On 11/21/06, David Chelimsky wrote: > > On 11/21/06, Brian Takita wrote: > > Also, my coworker, Benny Sadeh advised me to treat the Brown Bag as a > > discussion and exploration of what can be learned from BDD and rspec. > > Yes, yes, yes, yes! That is fantastic advice. > > Please report back to let us know how it all went. Good and/or bad. Aiee. It got postponed to next Wednesday. Good luck! > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061122/089fad00/attachment-0001.html From noreply at rubyforge.org Thu Nov 23 08:41:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 23 Nov 2006 08:41:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6835 ] bad message with arbitrary predicate Message-ID: <20061123134113.8F3BA5240E5E@rubyforge.org> Bugs item #6835, was opened at 2006-11-23 13:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6835&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: bad message with arbitrary predicate Initial Comment: #from failing_examples/predicate_example class BddFramework def adopted_quickly? #this will cause failures because it reallly SHOULD be adopted quickly false end end context "BDD framework" do setup do @bdd_framework = BddFramework.new end specify "should be adopted quickly" do @bdd_framework.should_be_adopted_quickly end end produces.... 1) 'BDD framework should be adopted quickly' FAILED # should adopted_quickly nil ./failing_examples/predicate_example.rb:22 NOTE: should adopted_quickly nil should read: should be adopted_quickly ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6835&group_id=797 From noreply at rubyforge.org Thu Nov 23 09:07:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 23 Nov 2006 09:07:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6835 ] bad message with arbitrary predicate Message-ID: <20061123140727.0748F5240ED8@rubyforge.org> Bugs item #6835, was opened at 2006-11-23 13:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6835&group_id=797 Category: expectation module Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: bad message with arbitrary predicate Initial Comment: #from failing_examples/predicate_example class BddFramework def adopted_quickly? #this will cause failures because it reallly SHOULD be adopted quickly false end end context "BDD framework" do setup do @bdd_framework = BddFramework.new end specify "should be adopted quickly" do @bdd_framework.should_be_adopted_quickly end end produces.... 1) 'BDD framework should be adopted quickly' FAILED # should adopted_quickly nil ./failing_examples/predicate_example.rb:22 NOTE: should adopted_quickly nil should read: should be adopted_quickly ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-23 14:07 Message: Fixed in trunk rev 1130 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6835&group_id=797 From noreply at rubyforge.org Thu Nov 23 12:56:47 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 23 Nov 2006 12:56:47 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6780 ] routing() was failing...fix included Message-ID: <20061123175647.3B9E15241037@rubyforge.org> Bugs item #6780, was opened at 2006-11-19 14:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Gustav Paul (gustavpaul) Assigned to: David Chelimsky (dchelimsky) Summary: routing() was failing...fix included Initial Comment: Hey I have the following route in my config/routes.rb: map.connect 'login', :controller => 'member', :action => 'login' my spec looks as follows #no def setup or anything similar... specify "/member/login should route to /login" do routing(:controller => 'member', :action => 'login').should_eql "/login" end Was failing, reporting inequality of 47 and '/login' "/login"[0] happened to be char code 47 I've got the rails plugin installed as /vendor/plugins/rspec_on_rails In /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb line #131 Was: ActionController::Routing::Routes.generate(options)[0] changed to ActionController::Routing::Routes.generate(options) Working perfectly now... Might have introduced other bugs, but I though I'd let you guys know... Cheery-o Gustav Paul gustav at rails.co.za ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-23 17:56 Message: Fixed in trunk rev 1132. This now works for Rails 1.1.6 and edge. ---------------------------------------------------------------------- Comment By: Gustav Paul (gustavpaul) Date: 2006-11-21 09:52 Message: First of all... I'm terribly sorry that I took so long to respond! Second... Yup, I'm on edge rails, I followed these guidelines if that's any help :] http://www.flpr.org/2006/11/15/edge-rspec-on-rails With only minor deviations... I ran svn exported rspec and the rspec_on_rails plugin instead of checking out. EDGE REVISION 5526 (according to /vendor/rails/) Thanks everyone, Gustav ---------------------------------------------------------------------- Comment By: Marcus Roberts (marcusr) Date: 2006-11-21 09:09 Message: I see the same problem. I'm running on edge rails (REVISION_5587) using RSPec gem 0.7.2 and Rspec Rails plugin checked out with ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec. Removing the [0] from the same line (line number 142 in my version) of /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb removes the error of "47 should == "/customers" in my own test Marcus ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 15:04 Message: He's probably on edge rails. I think edge rails and 1.1.6 rails behave differently. In edge rails the [0] must go away. Maybe we need to do different things based on RAILS_VERSION or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-20 03:36 Message: Gustav - I added a spec for this and it passed right away. It's committed in revision (1126). What version of RSpec were you using when this happened? Trunk revision? Rails version? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 From noreply at rubyforge.org Thu Nov 23 13:02:53 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 23 Nov 2006 13:02:53 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6780 ] routing() was failing...fix included Message-ID: <20061123180253.1BABA5241061@rubyforge.org> Bugs item #6780, was opened at 2006-11-19 16:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Gustav Paul (gustavpaul) Assigned to: David Chelimsky (dchelimsky) Summary: routing() was failing...fix included Initial Comment: Hey I have the following route in my config/routes.rb: map.connect 'login', :controller => 'member', :action => 'login' my spec looks as follows #no def setup or anything similar... specify "/member/login should route to /login" do routing(:controller => 'member', :action => 'login').should_eql "/login" end Was failing, reporting inequality of 47 and '/login' "/login"[0] happened to be char code 47 I've got the rails plugin installed as /vendor/plugins/rspec_on_rails In /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb line #131 Was: ActionController::Routing::Routes.generate(options)[0] changed to ActionController::Routing::Routes.generate(options) Working perfectly now... Might have introduced other bugs, but I though I'd let you guys know... Cheery-o Gustav Paul gustav at rails.co.za ---------------------------------------------------------------------- >Comment By: Gustav Paul (gustavpaul) Date: 2006-11-23 20:02 Message: Great! I'm curious as to how you fixed it? (reconciling 1.1.6 with edge?) Gustav ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-23 19:56 Message: Fixed in trunk rev 1132. This now works for Rails 1.1.6 and edge. ---------------------------------------------------------------------- Comment By: Gustav Paul (gustavpaul) Date: 2006-11-21 11:52 Message: First of all... I'm terribly sorry that I took so long to respond! Second... Yup, I'm on edge rails, I followed these guidelines if that's any help :] http://www.flpr.org/2006/11/15/edge-rspec-on-rails With only minor deviations... I ran svn exported rspec and the rspec_on_rails plugin instead of checking out. EDGE REVISION 5526 (according to /vendor/rails/) Thanks everyone, Gustav ---------------------------------------------------------------------- Comment By: Marcus Roberts (marcusr) Date: 2006-11-21 11:09 Message: I see the same problem. I'm running on edge rails (REVISION_5587) using RSPec gem 0.7.2 and Rspec Rails plugin checked out with ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec. Removing the [0] from the same line (line number 142 in my version) of /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb removes the error of "47 should == "/customers" in my own test Marcus ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 17:04 Message: He's probably on edge rails. I think edge rails and 1.1.6 rails behave differently. In edge rails the [0] must go away. Maybe we need to do different things based on RAILS_VERSION or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-20 05:36 Message: Gustav - I added a spec for this and it passed right away. It's committed in revision (1126). What version of RSpec were you using when this happened? Trunk revision? Rails version? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 From noreply at rubyforge.org Thu Nov 23 13:58:06 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 23 Nov 2006 13:58:06 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6780 ] routing() was failing...fix included Message-ID: <20061123185806.EA0AD52410F2@rubyforge.org> Bugs item #6780, was opened at 2006-11-19 14:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Gustav Paul (gustavpaul) Assigned to: David Chelimsky (dchelimsky) Summary: routing() was failing...fix included Initial Comment: Hey I have the following route in my config/routes.rb: map.connect 'login', :controller => 'member', :action => 'login' my spec looks as follows #no def setup or anything similar... specify "/member/login should route to /login" do routing(:controller => 'member', :action => 'login').should_eql "/login" end Was failing, reporting inequality of 47 and '/login' "/login"[0] happened to be char code 47 I've got the rails plugin installed as /vendor/plugins/rspec_on_rails In /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb line #131 Was: ActionController::Routing::Routes.generate(options)[0] changed to ActionController::Routing::Routes.generate(options) Working perfectly now... Might have introduced other bugs, but I though I'd let you guys know... Cheery-o Gustav Paul gustav at rails.co.za ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-23 18:58 Message: Actually I hadn't! But I have now as of rev 1134. The two versions handle routing differently. All I did was to check if we're getting a String or an Array. Pretty simple really. ---------------------------------------------------------------------- Comment By: Gustav Paul (gustavpaul) Date: 2006-11-23 18:02 Message: Great! I'm curious as to how you fixed it? (reconciling 1.1.6 with edge?) Gustav ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-23 17:56 Message: Fixed in trunk rev 1132. This now works for Rails 1.1.6 and edge. ---------------------------------------------------------------------- Comment By: Gustav Paul (gustavpaul) Date: 2006-11-21 09:52 Message: First of all... I'm terribly sorry that I took so long to respond! Second... Yup, I'm on edge rails, I followed these guidelines if that's any help :] http://www.flpr.org/2006/11/15/edge-rspec-on-rails With only minor deviations... I ran svn exported rspec and the rspec_on_rails plugin instead of checking out. EDGE REVISION 5526 (according to /vendor/rails/) Thanks everyone, Gustav ---------------------------------------------------------------------- Comment By: Marcus Roberts (marcusr) Date: 2006-11-21 09:09 Message: I see the same problem. I'm running on edge rails (REVISION_5587) using RSPec gem 0.7.2 and Rspec Rails plugin checked out with ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec. Removing the [0] from the same line (line number 142 in my version) of /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb removes the error of "47 should == "/customers" in my own test Marcus ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 15:04 Message: He's probably on edge rails. I think edge rails and 1.1.6 rails behave differently. In edge rails the [0] must go away. Maybe we need to do different things based on RAILS_VERSION or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-20 03:36 Message: Gustav - I added a spec for this and it passed right away. It's committed in revision (1126). What version of RSpec were you using when this happened? Trunk revision? Rails version? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 From noreply at rubyforge.org Thu Nov 23 15:09:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 23 Nov 2006 15:09:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6780 ] routing() was failing...fix included Message-ID: <20061123200957.EB9C052411C3@rubyforge.org> Bugs item #6780, was opened at 2006-11-19 16:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Gustav Paul (gustavpaul) Assigned to: David Chelimsky (dchelimsky) Summary: routing() was failing...fix included Initial Comment: Hey I have the following route in my config/routes.rb: map.connect 'login', :controller => 'member', :action => 'login' my spec looks as follows #no def setup or anything similar... specify "/member/login should route to /login" do routing(:controller => 'member', :action => 'login').should_eql "/login" end Was failing, reporting inequality of 47 and '/login' "/login"[0] happened to be char code 47 I've got the rails plugin installed as /vendor/plugins/rspec_on_rails In /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb line #131 Was: ActionController::Routing::Routes.generate(options)[0] changed to ActionController::Routing::Routes.generate(options) Working perfectly now... Might have introduced other bugs, but I though I'd let you guys know... Cheery-o Gustav Paul gustav at rails.co.za ---------------------------------------------------------------------- >Comment By: Gustav Paul (gustavpaul) Date: 2006-11-23 22:09 Message: Cool, makes sense :] Thanks for the effort dude! Ciao, Gustav ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-23 20:58 Message: Actually I hadn't! But I have now as of rev 1134. The two versions handle routing differently. All I did was to check if we're getting a String or an Array. Pretty simple really. ---------------------------------------------------------------------- Comment By: Gustav Paul (gustavpaul) Date: 2006-11-23 20:02 Message: Great! I'm curious as to how you fixed it? (reconciling 1.1.6 with edge?) Gustav ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-23 19:56 Message: Fixed in trunk rev 1132. This now works for Rails 1.1.6 and edge. ---------------------------------------------------------------------- Comment By: Gustav Paul (gustavpaul) Date: 2006-11-21 11:52 Message: First of all... I'm terribly sorry that I took so long to respond! Second... Yup, I'm on edge rails, I followed these guidelines if that's any help :] http://www.flpr.org/2006/11/15/edge-rspec-on-rails With only minor deviations... I ran svn exported rspec and the rspec_on_rails plugin instead of checking out. EDGE REVISION 5526 (according to /vendor/rails/) Thanks everyone, Gustav ---------------------------------------------------------------------- Comment By: Marcus Roberts (marcusr) Date: 2006-11-21 11:09 Message: I see the same problem. I'm running on edge rails (REVISION_5587) using RSPec gem 0.7.2 and Rspec Rails plugin checked out with ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec. Removing the [0] from the same line (line number 142 in my version) of /vendor/plugins/rspec_on_rails/lib/spec/rails/context/controller.rb removes the error of "47 should == "/customers" in my own test Marcus ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 17:04 Message: He's probably on edge rails. I think edge rails and 1.1.6 rails behave differently. In edge rails the [0] must go away. Maybe we need to do different things based on RAILS_VERSION or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-20 05:36 Message: Gustav - I added a spec for this and it passed right away. It's committed in revision (1126). What version of RSpec were you using when this happened? Trunk revision? Rails version? Thx ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6780&group_id=797 From noreply at rubyforge.org Fri Nov 24 17:05:34 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 24 Nov 2006 17:05:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6674 ] rspec_on_rails fails on @session deprecation warning? Message-ID: <20061124220534.71F7452412FE@rubyforge.org> Bugs item #6674, was opened at 2006-11-14 18:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6674&group_id=797 >Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Steve Ross (sxross) >Assigned to: David Chelimsky (dchelimsky) Summary: rspec_on_rails fails on @session deprecation warning? Initial Comment: rSpec 0.7.2 and rspec_on_rails 0.7.2 on Edge Rails (5473). I'm not certain that the deprecation warnings are causing this, but that's how it looks to me. By the way, the line 'puts self.class' outputs 'F'. Is this expected? Simple view test: require File.dirname(__FILE__) + '/../spec_helper' context "/member/index" do setup do @member = mock("member") @content_for_title = 'sign up for mailing list' @member.should_receive(:member) assigns[:member] = [@member] end specify "should show signup page" do puts self.class render '/member/index' response.should_have_tag 'div', attributes =>{:id => "intro"} end end Results: 1) RuntimeError in '/member/index should show signup page' Deprecating @session, but it's already set to #{}}>! Use the session= writer method instead of setting @session directly. /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1049:in `assign_deprecated_shortcuts' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1044:in `assign_deprecated_shortcuts' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1035:in `assign_shortcuts_without_flash' /Users/sxross/rails/kudzu/config/../vendor/rails/actionpack/lib/action_controller/flash.rb:140:in `assign_shortcuts' Finished in 0.063727 seconds 1 specification, 1 failure rake aborted! Command failed with status (1): [/usr/local/bin/ruby -I"/usr/local/lib/ruby...] ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:05 Message: I've put in a hack that will get us by for the time being (trunk rev 1136). Closing this for now. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-22 10:40 Message: Not so easy. Zen is gone from trunk and the problem still exists on edge rails. It has to do with a change in Rails from using @session to @_session. Not sure what the best course is here. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-20 15:06 Message: This is ZenTest's fault. This will go away when we get rid of ZenTest. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-19 20:30 Message: Moving this to bugs ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6674&group_id=797 From noreply at rubyforge.org Fri Nov 24 17:08:40 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 24 Nov 2006 17:08:40 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6577 ] messy mock backtrace when frozen to edge rails Message-ID: <20061124220840.2D0EF52412FE@rubyforge.org> Bugs item #6577, was opened at 2006-11-08 22:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6577&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: messy mock backtrace when frozen to edge rails Initial Comment: Once I freeze edge rails with rake rails:freeze:edge - even if I freeze it to 1.1.6 - the following app and spec cause a messy backtrace. This does not happen when rails is unfrozen. # app/controllers/test_controller.rb class TestController < ActionController::Base def index tm = TestMock.new tm.foo tm.bar end end class TestMock def foo end end # spec/controllers/one_spec.rb require File.dirname(__FILE__) + '/../spec_helper' context "the test app" do controller_name :test specify "should render the index page" do tm = mock("TestMock") TestMock.stub!(:new).and_return(tm) tm.should_receive(:foo) get 'index' end end # backtrace shown $ spec spec/controllers/one_spec.rb F 1) Spec::Mocks::MockExpectationError in 'the test app should render the index page' Mock 'TestMock' received unexpected message :bar /cygdrive/c/dev/src/eclipse/testapp/config/../app/controllers/test_controller.rb:6:in `index' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `perform_action_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:635:in `call_filter' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:622:in `perform_action_without_benchmark' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/rescue.rb:81:in `perform_action' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `process_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:627:in `process_without_session_management_support' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in `process_without_test' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process' ./spec/controllers/one_spec.rb:10:in `should render the index page' Finished in 0.197 seconds 1 specification, 1 failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:08 Message: Moving to patches. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-11-09 01:25 Message: Easier done than said! ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 23:44 Message: I think this can be fixed with a tweak in backtrace_tweaker.rb Could you try to create a patch since you already have the environment up? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6577&group_id=797 From noreply at rubyforge.org Fri Nov 24 17:11:29 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 24 Nov 2006 17:11:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6577 ] messy mock backtrace when frozen to edge rails Message-ID: <20061124221129.862F752412FE@rubyforge.org> Patches item #6577, was opened at 2006-11-08 22:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6577&group_id=797 >Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: messy mock backtrace when frozen to edge rails Initial Comment: Once I freeze edge rails with rake rails:freeze:edge - even if I freeze it to 1.1.6 - the following app and spec cause a messy backtrace. This does not happen when rails is unfrozen. # app/controllers/test_controller.rb class TestController < ActionController::Base def index tm = TestMock.new tm.foo tm.bar end end class TestMock def foo end end # spec/controllers/one_spec.rb require File.dirname(__FILE__) + '/../spec_helper' context "the test app" do controller_name :test specify "should render the index page" do tm = mock("TestMock") TestMock.stub!(:new).and_return(tm) tm.should_receive(:foo) get 'index' end end # backtrace shown $ spec spec/controllers/one_spec.rb F 1) Spec::Mocks::MockExpectationError in 'the test app should render the index page' Mock 'TestMock' received unexpected message :bar /cygdrive/c/dev/src/eclipse/testapp/config/../app/controllers/test_controller.rb:6:in `index' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `perform_action_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:635:in `call_filter' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:622:in `perform_action_without_benchmark' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/rescue.rb:81:in `perform_action' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `process_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:627:in `process_without_session_management_support' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in `process_without_test' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process' ./spec/controllers/one_spec.rb:10:in `should render the index page' Finished in 0.197 seconds 1 specification, 1 failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:11 Message: OK, really moving to patches. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:08 Message: Moving to patches. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-11-09 01:25 Message: Easier done than said! ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 23:44 Message: I think this can be fixed with a tweak in backtrace_tweaker.rb Could you try to create a patch since you already have the environment up? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6577&group_id=797 From noreply at rubyforge.org Fri Nov 24 17:12:48 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 24 Nov 2006 17:12:48 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6577 ] messy mock backtrace when frozen to edge rails Message-ID: <20061124221248.424BF5241145@rubyforge.org> Patches item #6577, was opened at 2006-11-08 22:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6577&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: messy mock backtrace when frozen to edge rails Initial Comment: Once I freeze edge rails with rake rails:freeze:edge - even if I freeze it to 1.1.6 - the following app and spec cause a messy backtrace. This does not happen when rails is unfrozen. # app/controllers/test_controller.rb class TestController < ActionController::Base def index tm = TestMock.new tm.foo tm.bar end end class TestMock def foo end end # spec/controllers/one_spec.rb require File.dirname(__FILE__) + '/../spec_helper' context "the test app" do controller_name :test specify "should render the index page" do tm = mock("TestMock") TestMock.stub!(:new).and_return(tm) tm.should_receive(:foo) get 'index' end end # backtrace shown $ spec spec/controllers/one_spec.rb F 1) Spec::Mocks::MockExpectationError in 'the test app should render the index page' Mock 'TestMock' received unexpected message :bar /cygdrive/c/dev/src/eclipse/testapp/config/../app/controllers/test_controller.rb:6:in `index' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `perform_action_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:635:in `call_filter' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:622:in `perform_action_without_benchmark' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/rescue.rb:81:in `perform_action' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `process_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:627:in `process_without_session_management_support' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in `process_without_test' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process' ./spec/controllers/one_spec.rb:10:in `should render the index page' Finished in 0.197 seconds 1 specification, 1 failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:12 Message: Applied to trunk rev 1137 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:11 Message: OK, really moving to patches. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:08 Message: Moving to patches. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-11-09 01:25 Message: Easier done than said! ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 23:44 Message: I think this can be fixed with a tweak in backtrace_tweaker.rb Could you try to create a patch since you already have the environment up? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6577&group_id=797 From noreply at rubyforge.org Fri Nov 24 17:13:06 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 24 Nov 2006 17:13:06 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6577 ] messy mock backtrace when frozen to edge rails Message-ID: <20061124221307.039DF52412F9@rubyforge.org> Patches item #6577, was opened at 2006-11-08 22:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6577&group_id=797 >Category: expectation module Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) >Assigned to: David Chelimsky (dchelimsky) Summary: messy mock backtrace when frozen to edge rails Initial Comment: Once I freeze edge rails with rake rails:freeze:edge - even if I freeze it to 1.1.6 - the following app and spec cause a messy backtrace. This does not happen when rails is unfrozen. # app/controllers/test_controller.rb class TestController < ActionController::Base def index tm = TestMock.new tm.foo tm.bar end end class TestMock def foo end end # spec/controllers/one_spec.rb require File.dirname(__FILE__) + '/../spec_helper' context "the test app" do controller_name :test specify "should render the index page" do tm = mock("TestMock") TestMock.stub!(:new).and_return(tm) tm.should_receive(:foo) get 'index' end end # backtrace shown $ spec spec/controllers/one_spec.rb F 1) Spec::Mocks::MockExpectationError in 'the test app should render the index page' Mock 'TestMock' received unexpected message :bar /cygdrive/c/dev/src/eclipse/testapp/config/../app/controllers/test_controller.rb:6:in `index' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:1070:in `perform_action_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:635:in `call_filter' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:622:in `perform_action_without_benchmark' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/rescue.rb:81:in `perform_action' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `send' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/base.rb:427:in `process_without_filters' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/filters.rb:627:in `process_without_session_management_support' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in `process_without_test' /cygdrive/c/dev/src/eclipse/testapp/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process' ./spec/controllers/one_spec.rb:10:in `should render the index page' Finished in 0.197 seconds 1 specification, 1 failure ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:12 Message: Applied to trunk rev 1137 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:11 Message: OK, really moving to patches. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:08 Message: Moving to patches. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-11-09 01:25 Message: Easier done than said! ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-08 23:44 Message: I think this can be fixed with a tweak in backtrace_tweaker.rb Could you try to create a patch since you already have the environment up? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6577&group_id=797 From noreply at rubyforge.org Fri Nov 24 17:18:00 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 24 Nov 2006 17:18:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6760 ] fatal error when accessing nested finders in rspec Message-ID: <20061124221800.673885241145@rubyforge.org> Bugs item #6760, was opened at 2006-11-18 05:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6760&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chad Humphries (spicycode) >Assigned to: David Chelimsky (dchelimsky) Summary: fatal error when accessing nested finders in rspec Initial Comment: We have several models that have relationships defined like this (on edge rails): has_many :items do def incomplete find(:all, :conditions => 'completed_at is null') end def complete find(:all, :conditions => 'completed_at is not null') end end This let's you do things like object.items.incomplete and object.items.complete... however in rspec if you try to use a model that has this type of collection in 0.7.X and up you get a repeating error (2-3 pages of it) after a long delay (30-90 seconds) that says something along the lines of: [project_path]/config/../vendor/rails/activerecord/lib/active_record/associations/has_many_association.rb:98:in `method_missing' If you remove the nested finders (ie change it to just be has_many :items) it works fine again. I'll try to investigate and see if I can find the cause, submitting as bug as it's rather late here. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 22:18 Message: This one is going to stay broken until 0.8 because commenting that out will bring back another bug. This is all related to conflicts between RSpec's and Rails' use of method_missing. 0.8 will remove RSpec's use of method missing on Object. ---------------------------------------------------------------------- Comment By: Chad Humphries (spicycode) Date: 2006-11-18 16:17 Message: It looks like the line: ActiveRecord::Associations::HasManyAssociation.handle_underscores_for_rspec! is causing it. If I comment it out in the plugin (0.7.2) things start working again in tests against models with this type of association. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6760&group_id=797 From dchelimsky at gmail.com Fri Nov 24 20:25:17 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 24 Nov 2006 19:25:17 -0600 Subject: [rspec-devel] [ANN] RSpec 0.7.3 Message-ID: <57c63afe0611241725s175f1252pa9f9daa9fcac885@mail.gmail.com> Hi all, I just released RSpec 0.7.3. It's got a few bug fixes and the rails plugin *should* run against both Rails 1.1.6 and 1.2.0-RC1. If you run into problems, please report bugs and feature requests in the tracker at rubyforge: http://rubyforge.org/tracker/?group_id=797 Cheers, David From noreply at rubyforge.org Fri Nov 24 20:30:40 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 24 Nov 2006 20:30:40 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator Message-ID: <20061125013041.18E0D52413A5@rubyforge.org> Feature Requests item #6098, was opened at 2006-10-11 10:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Make scaffold_resource generator Initial Comment: In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-25 01:30 Message: Hey Pat - I went to http://svn.flpr.org/public/plugins/rspec_resource_generator to grab the latest source and couldn't get to it (can't even ping flpr.org). Would you mind posting a new link to it, or just attaching a patch to this ticket? I'd like to get this in soon. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 16:54 Message: I think the routing patch should be applied separately in spec/rails. We have to make it work with both 1.1.6 and Edge Rails. This brings up another issue - our build system needs to be able to run all spec/rails specs several times, typically once for the latest Rails release and once for edge. -Possibly with a mechanism to differentiate what's being run depending on the Rails version. I think the most pragmatic way to verify that this (and other generators) is working is to have the rake script (bootstrap_rspec.rake) execute the various generators before specs are run. And then delete the generated files afterwards (or maybe right before they're generated). This would require that we change the templates - right now they fail on purpose with "not enough specs". We should be able to generate stuff and have all specs pass. If you could help with any of this it would be fabulous! ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-09 16:35 Message: I applied the patch. Sorry about the routing method error...I completely forgot I had that in there. I saw your comment in http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6471&group_id=797 that it doesn't work in 1.1.6. What would you like me to do for this plugin? Should I move the routing method into the plugin itself? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 14:17 Message: I'm attaching a patch with some small improvements: should_eql and correct use of controller_class_name ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 13:41 Message: Looks like routing is defined in this "patch": http://rubyforge.org/tracker/index.php?func=detail&aid=6471&group_id=797&atid=3152 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 13:34 Message: I tried this with RSpec's demo app (vendor/rspec_on_rails) - I created an account resource. The following code is failing: NoMethodError in 'The accountsController should map { :controller => 'accounts', :action => 'show', :id => 1 } to /accounts/1' undefined method `routing' for #<#:0x3b2d680> Where is this routing method defined? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-04 16:49 Message: My plugin at http://svn.flpr.org/public/plugins/rspec_resource_generator/ handles that. I removed the forked code, so the only template now is the controller_spec. Everything else is pulled from the standard Rails generators, and the rspec_model generator for the model spec. Anything else that should be done with that? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-04 09:28 Message: We should *not* fork/copy Rails code. Reuse all the existing templates, swap the test generation with spec generation (our own template). See the implementation of rspec_model and rspec_controller generators. ---------------------------------------------------------------------- Comment By: Jeff Dean (jefdean) Date: 2006-10-30 08:09 Message: I've written an rspec_scaffold_resource generator and I'm just waiting to here back on a few questions about directory changes in trunk before submitting the patch - Jeff Dean ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 From noreply at rubyforge.org Fri Nov 24 22:58:04 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 24 Nov 2006 22:58:04 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6870 ] rspec on edge rails spec:controller fixture loading fails Message-ID: <20061125035804.1E63552413B8@rubyforge.org> Bugs item #6870, was opened at 2006-11-25 03:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6870&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: courtenay 3 (court3nay) Assigned to: Nobody (None) Summary: rspec on edge rails spec:controller fixture loading fails Initial Comment: as per http://rubyforge.org/pipermail/rspec-users/2006-November/000247.html since they made the fixture_path inheritable, we need to add that back in, or follow this workaround: in spec_helper.rb module Spec module Rails class EvalContext < Test::Unit::TestCase cattr_accessor :fixture_path ... end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6870&group_id=797 From noreply at rubyforge.org Sat Nov 25 10:31:25 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 25 Nov 2006 10:31:25 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6870 ] rspec on edge rails spec:controller fixture loading fails Message-ID: <20061125153125.C5BD45240D92@rubyforge.org> Bugs item #6870, was opened at 2006-11-25 03:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6870&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: courtenay 3 (court3nay) >Assigned to: David Chelimsky (dchelimsky) Summary: rspec on edge rails spec:controller fixture loading fails Initial Comment: as per http://rubyforge.org/pipermail/rspec-users/2006-November/000247.html since they made the fixture_path inheritable, we need to add that back in, or follow this workaround: in spec_helper.rb module Spec module Rails class EvalContext < Test::Unit::TestCase cattr_accessor :fixture_path ... end end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-25 15:31 Message: Fixed in trunk (rev 6870) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6870&group_id=797 From noreply at rubyforge.org Sat Nov 25 10:33:18 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 25 Nov 2006 10:33:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6870 ] rspec on edge rails spec:controller fixture loading fails Message-ID: <20061125153318.CAE175240D92@rubyforge.org> Bugs item #6870, was opened at 2006-11-25 03:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6870&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: None Priority: 3 Submitted By: courtenay 3 (court3nay) Assigned to: David Chelimsky (dchelimsky) Summary: rspec on edge rails spec:controller fixture loading fails Initial Comment: as per http://rubyforge.org/pipermail/rspec-users/2006-November/000247.html since they made the fixture_path inheritable, we need to add that back in, or follow this workaround: in spec_helper.rb module Spec module Rails class EvalContext < Test::Unit::TestCase cattr_accessor :fixture_path ... end end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-25 15:33 Message: D'oh! Trunk rev 1147. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-25 15:31 Message: Fixed in trunk (rev 6870) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6870&group_id=797 From aslak.hellesoy at gmail.com Sat Nov 25 14:39:24 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 25 Nov 2006 20:39:24 +0100 Subject: [rspec-devel] Splitting up the APIs Message-ID: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> Many people don't realise that RSpec can be used from within Test::Unit like this: require 'test/unit' require 'rubygems' require 'spec' class SpecTest < Test::Unit::TestCase def test_hello_should_be_of_length_four "hello".length.should_be 4 end end Christian (http://tinyurl.com/sr665) and Rick (http://tinyurl.com/y736tq) have taken the ideas they like from RSpec, reimplemented it in their own way (NIH) and released it to the public. Competition is good - as long as it brings something new to the table. I'm not sure what these two clones do better though. Anyway, I think now is a good time to split RSpec up in three parts: * should_expectations.gem * rspec_context.gem * rspec_mock.gem Hopefully this will reduce people's urge to replicate RSpec's ideas - because they can pick what they need. Of course, it's possible to cherry-pick what you need from RSpec in its current form, but people have a strange tendency to feel uneasy when they only use parts of a library. It's weird. Aslak From dchelimsky at gmail.com Sat Nov 25 14:48:12 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 25 Nov 2006 13:48:12 -0600 Subject: [rspec-devel] Splitting up the APIs In-Reply-To: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> References: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> Message-ID: <57c63afe0611251148m134e3811mda9acd01f2b593f0@mail.gmail.com> On 11/25/06, aslak hellesoy wrote: > Many people don't realise that RSpec can be used from within > Test::Unit like this: > > require 'test/unit' > require 'rubygems' > require 'spec' > > class SpecTest < Test::Unit::TestCase > def test_hello_should_be_of_length_four > "hello".length.should_be 4 > end > end > > Christian (http://tinyurl.com/sr665) and Rick > (http://tinyurl.com/y736tq) have taken the ideas they like from RSpec, > reimplemented it in their own way (NIH) and released it to the public. > Competition is good - as long as it brings something new to the table. > I'm not sure what these two clones do better though. > > Anyway, I think now is a good time to split RSpec up in three parts: > > * should_expectations.gem > * rspec_context.gem > * rspec_mock.gem For consistency, could we call the first one rspec_expectations.gem? Otherwise I like this idea a lot. > Hopefully this will reduce people's urge to replicate RSpec's ideas - > because they can pick what they need. > > Of course, it's possible to cherry-pick what you need from RSpec in > its current form, but people have a strange tendency to feel uneasy > when they only use parts of a library. It's weird. > > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brian.takita at gmail.com Sat Nov 25 15:07:52 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 25 Nov 2006 12:07:52 -0800 Subject: [rspec-devel] Splitting up the APIs In-Reply-To: <57c63afe0611251148m134e3811mda9acd01f2b593f0@mail.gmail.com> References: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> <57c63afe0611251148m134e3811mda9acd01f2b593f0@mail.gmail.com> Message-ID: <1d7ddd110611251207l568a9903pb6c036deee6d0db9@mail.gmail.com> On 11/25/06, David Chelimsky wrote: > > On 11/25/06, aslak hellesoy wrote: > > Many people don't realise that RSpec can be used from within > > Test::Unit like this: > > > > require 'test/unit' > > require 'rubygems' > > require 'spec' > > > > class SpecTest < Test::Unit::TestCase > > def test_hello_should_be_of_length_four > > "hello".length.should_be 4 > > end > > end > > > > Christian (http://tinyurl.com/sr665) and Rick > > (http://tinyurl.com/y736tq) have taken the ideas they like from RSpec, > > reimplemented it in their own way (NIH) and released it to the public. > > Competition is good - as long as it brings something new to the table. > > I'm not sure what these two clones do better though. > > > > Anyway, I think now is a good time to split RSpec up in three parts: > > > > * should_expectations.gem > > * rspec_context.gem > > * rspec_mock.gem > > For consistency, could we call the first one rspec_expectations.gem? > > Otherwise I like this idea a lot. +1 > Hopefully this will reduce people's urge to replicate RSpec's ideas - > > because they can pick what they need. > > > > Of course, it's possible to cherry-pick what you need from RSpec in > > its current form, but people have a strange tendency to feel uneasy > > when they only use parts of a library. It's weird. > > > > Aslak > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061125/85dc2c77/attachment.html From contact at lukeredpath.co.uk Sat Nov 25 15:36:05 2006 From: contact at lukeredpath.co.uk (Luke Redpath) Date: Sat, 25 Nov 2006 20:36:05 +0000 Subject: [rspec-devel] Splitting up the APIs In-Reply-To: <1d7ddd110611251207l568a9903pb6c036deee6d0db9@mail.gmail.com> References: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> <57c63afe0611251148m134e3811mda9acd01f2b593f0@mail.gmail.com> <1d7ddd110611251207l568a9903pb6c036deee6d0db9@mail.gmail.com> Message-ID: As I said on Rick's blog comments, I think this would be a good idea, so a big +1. It would be nice to maintain some kind of meta-package (rspec) that installs all of them - I don't know how easy or difficult that is with rubygems, I've never done it. Cheers Luke On 25 Nov 2006, at 20:07, Brian Takita wrote: > On 11/25/06, David Chelimsky wrote: > On 11/25/06, aslak hellesoy wrote: > > Many people don't realise that RSpec can be used from within > > Test::Unit like this: > > > > require 'test/unit' > > require 'rubygems' > > require 'spec' > > > > class SpecTest < Test::Unit::TestCase > > def test_hello_should_be_of_length_four > > "hello".length.should_be 4 > > end > > end > > > > Christian (http://tinyurl.com/sr665) and Rick > > (http://tinyurl.com/y736tq) have taken the ideas they like from > RSpec, > > reimplemented it in their own way (NIH) and released it to the > public. > > Competition is good - as long as it brings something new to the > table. > > I'm not sure what these two clones do better though. > > > > Anyway, I think now is a good time to split RSpec up in three parts: > > > > * should_expectations.gem > > * rspec_context.gem > > * rspec_mock.gem > > For consistency, could we call the first one rspec_expectations.gem? > > Otherwise I like this idea a lot. > > +1 > > > Hopefully this will reduce people's urge to replicate RSpec's > ideas - > > because they can pick what they need. > > > > Of course, it's possible to cherry-pick what you need from RSpec in > > its current form, but people have a strange tendency to feel uneasy > > when they only use parts of a library. It's weird. > > > > Aslak > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061125/2d38493a/attachment.html From aslak.hellesoy at gmail.com Sat Nov 25 16:00:35 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 25 Nov 2006 22:00:35 +0100 Subject: [rspec-devel] Splitting up the APIs In-Reply-To: References: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> <57c63afe0611251148m134e3811mda9acd01f2b593f0@mail.gmail.com> <1d7ddd110611251207l568a9903pb6c036deee6d0db9@mail.gmail.com> Message-ID: <8d961d900611251300h3c27324am44435b00960bf239@mail.gmail.com> On 11/25/06, Luke Redpath wrote: > > As I said on Rick's blog comments, I think this would be a good idea, so a > big +1. > I'm not completely convinced it's a good idea to split things up. The build system would become more complex (circular dependencies if we continue to use rspec). What exactly would be the benefits that we don't have today? Aslak > It would be nice to maintain some kind of meta-package (rspec) that installs > all of them - I don't know how easy or difficult that is with rubygems, I've > never done it. > > Cheers > Luke > > > On 25 Nov 2006, at 20:07, Brian Takita wrote: > On 11/25/06, David Chelimsky wrote: > > On 11/25/06, aslak hellesoy wrote: > > > Many people don't realise that RSpec can be used from within > > > Test::Unit like this: > > > > > > require 'test/unit' > > > require 'rubygems' > > > require 'spec' > > > > > > class SpecTest < Test::Unit::TestCase > > > def test_hello_should_be_of_length_four > > > "hello".length.should_be 4 > > > end > > > end > > > > > > Christian (http://tinyurl.com/sr665) and Rick > > > (http://tinyurl.com/y736tq) have taken the ideas they like from RSpec, > > > reimplemented it in their own way (NIH) and released it to the public. > > > Competition is good - as long as it brings something new to the table. > > > I'm not sure what these two clones do better though. > > > > > > Anyway, I think now is a good time to split RSpec up in three parts: > > > > > > * should_expectations.gem > > > * rspec_context.gem > > > * rspec_mock.gem > > > > For consistency, could we call the first one rspec_expectations.gem? > > > > Otherwise I like this idea a lot. > > +1 > > > > Hopefully this will reduce people's urge to replicate RSpec's ideas - > > > because they can pick what they need. > > > > > > Of course, it's possible to cherry-pick what you need from RSpec in > > > its current form, but people have a strange tendency to feel uneasy > > > when they only use parts of a library. It's weird. > > > > > > Aslak > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From noreply at rubyforge.org Sat Nov 25 17:29:42 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 25 Nov 2006 17:29:42 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6884 ] intermittent errors related to method binding Message-ID: <20061125222942.A8F7D5241421@rubyforge.org> Bugs item #6884, was opened at 2006-11-25 22:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6884&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: intermittent errors related to method binding Initial Comment: >From this email: http://rubyforge.org/pipermail/rspec-users/2006-November/000239.html .. and similar. There have been some reports of errors like this: undefined method `render?' for # I *think* that I have traced it to a bug in Rails' Proc#bind. It uses the current time to name methods which get bound and unbound. I believe this could be creating some conflict in which two methods get named the same and the wrong method gets unbound. I've submitted patch 6703 to Rails, and will include the fix for this in RSpec until such time as it is accepted (if it is). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6884&group_id=797 From noreply at rubyforge.org Sat Nov 25 17:31:29 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 25 Nov 2006 17:31:29 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6884 ] intermittent errors related to method binding Message-ID: <20061125223129.2D5AA5241428@rubyforge.org> Bugs item #6884, was opened at 2006-11-25 22:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6884&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: intermittent errors related to method binding Initial Comment: >From this email: http://rubyforge.org/pipermail/rspec-users/2006-November/000239.html .. and similar. There have been some reports of errors like this: undefined method `render?' for # I *think* that I have traced it to a bug in Rails' Proc#bind. It uses the current time to name methods which get bound and unbound. I believe this could be creating some conflict in which two methods get named the same and the wrong method gets unbound. I've submitted patch 6703 to Rails, and will include the fix for this in RSpec until such time as it is accepted (if it is). ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-25 22:31 Message: Fixed in trunk (rev 1150) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6884&group_id=797 From brian.takita at gmail.com Sat Nov 25 17:34:41 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 25 Nov 2006 14:34:41 -0800 Subject: [rspec-devel] Splitting up the APIs In-Reply-To: <8d961d900611251300h3c27324am44435b00960bf239@mail.gmail.com> References: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> <57c63afe0611251148m134e3811mda9acd01f2b593f0@mail.gmail.com> <1d7ddd110611251207l568a9903pb6c036deee6d0db9@mail.gmail.com> <8d961d900611251300h3c27324am44435b00960bf239@mail.gmail.com> Message-ID: <1d7ddd110611251434n78170e6ei8c1a0041a10fad0b@mail.gmail.com> On 11/25/06, aslak hellesoy wrote: > > On 11/25/06, Luke Redpath wrote: > > > > As I said on Rick's blog comments, I think this would be a good idea, so > a > > big +1. > > > > I'm not completely convinced it's a good idea to split things up. The > build system would become more complex (circular dependencies if we > continue to use rspec). > > What exactly would be the benefits that we don't have today? You may be right... For expectations one can: require 'spec/expectations' and for mocks: require 'spec/mocks' The only benefit that I can think of is it would draw more attention to each specific module of rspec. Aslak > > > It would be nice to maintain some kind of meta-package (rspec) that > installs > > all of them - I don't know how easy or difficult that is with rubygems, > I've > > never done it. Its very easy. Just call add_dependency in the Gem definition. > > > Cheers > > Luke > > > > > > On 25 Nov 2006, at 20:07, Brian Takita wrote: > > On 11/25/06, David Chelimsky wrote: > > > On 11/25/06, aslak hellesoy wrote: > > > > Many people don't realise that RSpec can be used from within > > > > Test::Unit like this: > > > > > > > > require 'test/unit' > > > > require 'rubygems' > > > > require 'spec' > > > > > > > > class SpecTest < Test::Unit::TestCase > > > > def test_hello_should_be_of_length_four > > > > "hello".length.should_be 4 > > > > end > > > > end > > > > > > > > Christian (http://tinyurl.com/sr665) and Rick > > > > (http://tinyurl.com/y736tq) have taken the ideas they like from > RSpec, > > > > reimplemented it in their own way (NIH) and released it to the > public. > > > > Competition is good - as long as it brings something new to the > table. > > > > I'm not sure what these two clones do better though. > > > > > > > > Anyway, I think now is a good time to split RSpec up in three parts: > > > > > > > > * should_expectations.gem > > > > * rspec_context.gem > > > > * rspec_mock.gem > > > > > > For consistency, could we call the first one rspec_expectations.gem? > > > > > > Otherwise I like this idea a lot. > > > > +1 > > > > > > Hopefully this will reduce people's urge to replicate RSpec's ideas > - > > > > because they can pick what they need. > > > > > > > > Of course, it's possible to cherry-pick what you need from RSpec in > > > > its current form, but people have a strange tendency to feel uneasy > > > > when they only use parts of a library. It's weird. > > > > > > > > Aslak > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061125/e3b10d89/attachment.html From wilsonb at gmail.com Sat Nov 25 19:07:03 2006 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Sat, 25 Nov 2006 19:07:03 -0500 Subject: [rspec-devel] Splitting up the APIs In-Reply-To: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> References: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> Message-ID: On 11/25/06, aslak hellesoy wrote: > Christian (http://tinyurl.com/sr665) and Rick > (http://tinyurl.com/y736tq) have taken the ideas they like from RSpec, > reimplemented it in their own way (NIH) and released it to the public. > Competition is good - as long as it brings something new to the table. > I'm not sure what these two clones do better though. > They don't change the API every 12 seconds. =( I've considered switching to Chrstian's even though I would miss certain RSpec features, simply because it is less of a moving target. From jay at jayfields.com Sat Nov 25 20:01:29 2006 From: jay at jayfields.com (Jay) Date: Sat, 25 Nov 2006 20:01:29 -0500 Subject: [rspec-devel] Splitting up the APIs In-Reply-To: References: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> Message-ID: <769E4C8D-1EC4-4AA6-A149-F56843E58842@jayfields.com> You can (and probably should) unpack a particular gem locally in your project. At that point, the API wont change at all. This doesn't solve your problems when you need a new version of the gem, but if the gem already does everything you need then it might help. Jay On Nov 25, 2006, at 7:07 PM, Wilson Bilkovich wrote: > On 11/25/06, aslak hellesoy wrote: >> Christian (http://tinyurl.com/sr665) and Rick >> (http://tinyurl.com/y736tq) have taken the ideas they like from >> RSpec, >> reimplemented it in their own way (NIH) and released it to the >> public. >> Competition is good - as long as it brings something new to the >> table. >> I'm not sure what these two clones do better though. >> > > They don't change the API every 12 seconds. =( > > I've considered switching to Chrstian's even though I would miss > certain RSpec features, simply because it is less of a moving target. > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Sat Nov 25 22:50:10 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 25 Nov 2006 21:50:10 -0600 Subject: [rspec-devel] Splitting up the APIs In-Reply-To: <769E4C8D-1EC4-4AA6-A149-F56843E58842@jayfields.com> References: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> <769E4C8D-1EC4-4AA6-A149-F56843E58842@jayfields.com> Message-ID: <57c63afe0611251950y6c9c9aafq147f60be26926796@mail.gmail.com> On 11/25/06, Jay wrote: > You can (and probably should) unpack a particular gem locally in your > project. At that point, the API wont change at all. This doesn't > solve your problems when you need a new version of the gem, but if > the gem already does everything you need then it might help. > Jay That is sound advice. It gives you much more control over when you absorb changes. Thanks Jay! David > > On Nov 25, 2006, at 7:07 PM, Wilson Bilkovich wrote: > > > On 11/25/06, aslak hellesoy wrote: > >> Christian (http://tinyurl.com/sr665) and Rick > >> (http://tinyurl.com/y736tq) have taken the ideas they like from > >> RSpec, > >> reimplemented it in their own way (NIH) and released it to the > >> public. > >> Competition is good - as long as it brings something new to the > >> table. > >> I'm not sure what these two clones do better though. > >> > > > > They don't change the API every 12 seconds. =( > > > > I've considered switching to Chrstian's even though I would miss > > certain RSpec features, simply because it is less of a moving target. > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun Nov 26 06:21:59 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 06:21:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6889 ] Mock expectations not satisfied by code in view Message-ID: <20061126112159.DD7EE5240E1B@rubyforge.org> Bugs item #6889, was opened at 2006-11-26 04:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Mock expectations not satisfied by code in view Initial Comment: Consider this method: def create_user @u = mock("user") @u.should_receive(:people).and_return([OpenStruct.new(:name => 'Justin'), OpenStruct.new(:name => 'BJ')]) User.should_receive(:find_by_login).with('pat').and_return(@u) end Now the setup for this spec is: setup do create_user get :show, :id => 'pat' end Controller code is: def show @user = User.find_by_login params[:id] end And then the view: <% @user.people.each do |p| %> <%= h p.name %> <% end %> The mock object @u expects the people method to be called. It is called in the view. However when I run the spec, I get "Mock 'user' expected :people once, but received it 0 times" Is this expected behavior? If so, why? I haven't found anything in the list archives or previous bug reports. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 From noreply at rubyforge.org Sun Nov 26 07:22:37 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 07:22:37 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6889 ] Mock expectations not satisfied by code in view Message-ID: <20061126122237.53CF75240E59@rubyforge.org> Bugs item #6889, was opened at 2006-11-26 06:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Mock expectations not satisfied by code in view Initial Comment: Consider this method: def create_user @u = mock("user") @u.should_receive(:people).and_return([OpenStruct.new(:name => 'Justin'), OpenStruct.new(:name => 'BJ')]) User.should_receive(:find_by_login).with('pat').and_return(@u) end Now the setup for this spec is: setup do create_user get :show, :id => 'pat' end Controller code is: def show @user = User.find_by_login params[:id] end And then the view: <% @user.people.each do |p| %> <%= h p.name %> <% end %> The mock object @u expects the people method to be called. It is called in the view. However when I run the spec, I get "Mock 'user' expected :people once, but received it 0 times" Is this expected behavior? If so, why? I haven't found anything in the list archives or previous bug reports. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 07:22 Message: * What versions/revisions of RSpec/Rails are you using? * Is this a controller spec or a view spec. Are you using integrated views (http://rspec.rubyforge.org/documentation/rails/writing/controllers.html)? * Can you help us reproduce this failure by modifying the demo app in rspec_on_rails and send us a patch file? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 From noreply at rubyforge.org Sun Nov 26 07:26:49 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 07:26:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6889 ] Mock expectations not satisfied by code in view Message-ID: <20061126122649.88FE95240E68@rubyforge.org> Bugs item #6889, was opened at 2006-11-26 06:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Mock expectations not satisfied by code in view Initial Comment: Consider this method: def create_user @u = mock("user") @u.should_receive(:people).and_return([OpenStruct.new(:name => 'Justin'), OpenStruct.new(:name => 'BJ')]) User.should_receive(:find_by_login).with('pat').and_return(@u) end Now the setup for this spec is: setup do create_user get :show, :id => 'pat' end Controller code is: def show @user = User.find_by_login params[:id] end And then the view: <% @user.people.each do |p| %> <%= h p.name %> <% end %> The mock object @u expects the people method to be called. It is called in the view. However when I run the spec, I get "Mock 'user' expected :people once, but received it 0 times" Is this expected behavior? If so, why? I haven't found anything in the list archives or previous bug reports. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 07:26 Message: If your spec is a controller spec AND you haven't explicitly enabled view integration (using integrate_views) then RSpec will not invoke the view at all (which would explain your failure). This is a feature. For more info see http://rspec.rubyforge.org/documentation/rails/writing/controllers.html http://rspec.rubyforge.org/documentation/rails/writing/views.html ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 07:22 Message: * What versions/revisions of RSpec/Rails are you using? * Is this a controller spec or a view spec. Are you using integrated views (http://rspec.rubyforge.org/documentation/rails/writing/controllers.html)? * Can you help us reproduce this failure by modifying the demo app in rspec_on_rails and send us a patch file? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 From noreply at rubyforge.org Sun Nov 26 07:44:35 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 07:44:35 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6889 ] Mock expectations not satisfied by code in view Message-ID: <20061126124435.B35D95240E68@rubyforge.org> Bugs item #6889, was opened at 2006-11-26 06:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Mock expectations not satisfied by code in view Initial Comment: Consider this method: def create_user @u = mock("user") @u.should_receive(:people).and_return([OpenStruct.new(:name => 'Justin'), OpenStruct.new(:name => 'BJ')]) User.should_receive(:find_by_login).with('pat').and_return(@u) end Now the setup for this spec is: setup do create_user get :show, :id => 'pat' end Controller code is: def show @user = User.find_by_login params[:id] end And then the view: <% @user.people.each do |p| %> <%= h p.name %> <% end %> The mock object @u expects the people method to be called. It is called in the view. However when I run the spec, I get "Mock 'user' expected :people once, but received it 0 times" Is this expected behavior? If so, why? I haven't found anything in the list archives or previous bug reports. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 07:44 Message: As an example of what I'm asking for I have attached a patch created with the following command: aslak-hellesoys-computer-2:~/scm/rspec/trunk/vendor/rspec_on_rails aslakhellesoy$ svn diff > example_patch.diff The spec passes - I can't reproduce your problem. I think your spec is a controller spec and if you call integrate_views at the top of your spec I think your spec will pass. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 07:26 Message: If your spec is a controller spec AND you haven't explicitly enabled view integration (using integrate_views) then RSpec will not invoke the view at all (which would explain your failure). This is a feature. For more info see http://rspec.rubyforge.org/documentation/rails/writing/controllers.html http://rspec.rubyforge.org/documentation/rails/writing/views.html ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 07:22 Message: * What versions/revisions of RSpec/Rails are you using? * Is this a controller spec or a view spec. Are you using integrated views (http://rspec.rubyforge.org/documentation/rails/writing/controllers.html)? * Can you help us reproduce this failure by modifying the demo app in rspec_on_rails and send us a patch file? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 From wilsonb at gmail.com Sun Nov 26 10:41:31 2006 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Sun, 26 Nov 2006 10:41:31 -0500 Subject: [rspec-devel] Splitting up the APIs In-Reply-To: <57c63afe0611251950y6c9c9aafq147f60be26926796@mail.gmail.com> References: <8d961d900611251139r6faf96e1g7a57a35be0387fe@mail.gmail.com> <769E4C8D-1EC4-4AA6-A149-F56843E58842@jayfields.com> <57c63afe0611251950y6c9c9aafq147f60be26926796@mail.gmail.com> Message-ID: On 11/25/06, David Chelimsky wrote: > On 11/25/06, Jay wrote: > > You can (and probably should) unpack a particular gem locally in your > > project. At that point, the API wont change at all. This doesn't > > solve your problems when you need a new version of the gem, but if > > the gem already does everything you need then it might help. > > Jay > > That is sound advice. It gives you much more control over when you > absorb changes. > So you would recommend unpacking the rspec gem as well as the rspec_on_rails plugin? The dependency between the two is what has been giving me headaches. I don't mind adjusting to API changes as long as they are 'going somewhere'. I'm just worried that we're in (buzzword of the year) bikeshed territory. From noreply at rubyforge.org Sun Nov 26 15:18:23 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 15:18:23 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator Message-ID: <20061126201823.908D75241517@rubyforge.org> Feature Requests item #6098, was opened at 2006-10-11 06:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Make scaffold_resource generator Initial Comment: In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 15:18 Message: Luckliy I happened to have a copy of the code locally before the svn disappeared. I have attached it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-24 20:30 Message: Hey Pat - I went to http://svn.flpr.org/public/plugins/rspec_resource_generator to grab the latest source and couldn't get to it (can't even ping flpr.org). Would you mind posting a new link to it, or just attaching a patch to this ticket? I'd like to get this in soon. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 11:54 Message: I think the routing patch should be applied separately in spec/rails. We have to make it work with both 1.1.6 and Edge Rails. This brings up another issue - our build system needs to be able to run all spec/rails specs several times, typically once for the latest Rails release and once for edge. -Possibly with a mechanism to differentiate what's being run depending on the Rails version. I think the most pragmatic way to verify that this (and other generators) is working is to have the rake script (bootstrap_rspec.rake) execute the various generators before specs are run. And then delete the generated files afterwards (or maybe right before they're generated). This would require that we change the templates - right now they fail on purpose with "not enough specs". We should be able to generate stuff and have all specs pass. If you could help with any of this it would be fabulous! ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-09 11:35 Message: I applied the patch. Sorry about the routing method error...I completely forgot I had that in there. I saw your comment in http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6471&group_id=797 that it doesn't work in 1.1.6. What would you like me to do for this plugin? Should I move the routing method into the plugin itself? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 09:17 Message: I'm attaching a patch with some small improvements: should_eql and correct use of controller_class_name ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:41 Message: Looks like routing is defined in this "patch": http://rubyforge.org/tracker/index.php?func=detail&aid=6471&group_id=797&atid=3152 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 08:34 Message: I tried this with RSpec's demo app (vendor/rspec_on_rails) - I created an account resource. The following code is failing: NoMethodError in 'The accountsController should map { :controller => 'accounts', :action => 'show', :id => 1 } to /accounts/1' undefined method `routing' for #<#:0x3b2d680> Where is this routing method defined? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-04 11:49 Message: My plugin at http://svn.flpr.org/public/plugins/rspec_resource_generator/ handles that. I removed the forked code, so the only template now is the controller_spec. Everything else is pulled from the standard Rails generators, and the rspec_model generator for the model spec. Anything else that should be done with that? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-04 04:28 Message: We should *not* fork/copy Rails code. Reuse all the existing templates, swap the test generation with spec generation (our own template). See the implementation of rspec_model and rspec_controller generators. ---------------------------------------------------------------------- Comment By: Jeff Dean (jefdean) Date: 2006-10-30 03:09 Message: I've written an rspec_scaffold_resource generator and I'm just waiting to here back on a few questions about directory changes in trunk before submitting the patch - Jeff Dean ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:25:08 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:25:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6889 ] Mock expectations not satisfied by code in view Message-ID: <20061126232508.430C1524179E@rubyforge.org> Bugs item #6889, was opened at 2006-11-26 04:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Mock expectations not satisfied by code in view Initial Comment: Consider this method: def create_user @u = mock("user") @u.should_receive(:people).and_return([OpenStruct.new(:name => 'Justin'), OpenStruct.new(:name => 'BJ')]) User.should_receive(:find_by_login).with('pat').and_return(@u) end Now the setup for this spec is: setup do create_user get :show, :id => 'pat' end Controller code is: def show @user = User.find_by_login params[:id] end And then the view: <% @user.people.each do |p| %> <%= h p.name %> <% end %> The mock object @u expects the people method to be called. It is called in the view. However when I run the spec, I get "Mock 'user' expected :people once, but received it 0 times" Is this expected behavior? If so, why? I haven't found anything in the list archives or previous bug reports. ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2006-11-26 16:25 Message: Alright, I hadn't seen that integrate_views. Haven't used rspec in like a week and a half :) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 05:44 Message: As an example of what I'm asking for I have attached a patch created with the following command: aslak-hellesoys-computer-2:~/scm/rspec/trunk/vendor/rspec_on_rails aslakhellesoy$ svn diff > example_patch.diff The spec passes - I can't reproduce your problem. I think your spec is a controller spec and if you call integrate_views at the top of your spec I think your spec will pass. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 05:26 Message: If your spec is a controller spec AND you haven't explicitly enabled view integration (using integrate_views) then RSpec will not invoke the view at all (which would explain your failure). This is a feature. For more info see http://rspec.rubyforge.org/documentation/rails/writing/controllers.html http://rspec.rubyforge.org/documentation/rails/writing/views.html ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 05:22 Message: * What versions/revisions of RSpec/Rails are you using? * Is this a controller spec or a view spec. Are you using integrated views (http://rspec.rubyforge.org/documentation/rails/writing/controllers.html)? * Can you help us reproduce this failure by modifying the demo app in rspec_on_rails and send us a patch file? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:25:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:25:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6889 ] Mock expectations not satisfied by code in view Message-ID: <20061126232526.F07685241798@rubyforge.org> Bugs item #6889, was opened at 2006-11-26 04:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 Category: mock module Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Mock expectations not satisfied by code in view Initial Comment: Consider this method: def create_user @u = mock("user") @u.should_receive(:people).and_return([OpenStruct.new(:name => 'Justin'), OpenStruct.new(:name => 'BJ')]) User.should_receive(:find_by_login).with('pat').and_return(@u) end Now the setup for this spec is: setup do create_user get :show, :id => 'pat' end Controller code is: def show @user = User.find_by_login params[:id] end And then the view: <% @user.people.each do |p| %> <%= h p.name %> <% end %> The mock object @u expects the people method to be called. It is called in the view. However when I run the spec, I get "Mock 'user' expected :people once, but received it 0 times" Is this expected behavior? If so, why? I haven't found anything in the list archives or previous bug reports. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 16:25 Message: Alright, I hadn't seen that integrate_views. Haven't used rspec in like a week and a half :) ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 05:44 Message: As an example of what I'm asking for I have attached a patch created with the following command: aslak-hellesoys-computer-2:~/scm/rspec/trunk/vendor/rspec_on_rails aslakhellesoy$ svn diff > example_patch.diff The spec passes - I can't reproduce your problem. I think your spec is a controller spec and if you call integrate_views at the top of your spec I think your spec will pass. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 05:26 Message: If your spec is a controller spec AND you haven't explicitly enabled view integration (using integrate_views) then RSpec will not invoke the view at all (which would explain your failure). This is a feature. For more info see http://rspec.rubyforge.org/documentation/rails/writing/controllers.html http://rspec.rubyforge.org/documentation/rails/writing/views.html ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 05:22 Message: * What versions/revisions of RSpec/Rails are you using? * Is this a controller spec or a view spec. Are you using integrated views (http://rspec.rubyforge.org/documentation/rails/writing/controllers.html)? * Can you help us reproduce this failure by modifying the demo app in rspec_on_rails and send us a patch file? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6889&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:27:36 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:27:36 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6895 ] should_render :action doesn't seem to work Message-ID: <20061126232736.E6EBF52417A0@rubyforge.org> Bugs item #6895, was opened at 2006-11-26 16:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: should_render :action doesn't seem to work Initial Comment: 0.7.3, edge rails, if I do specify "should show the form" do controller.should_render :action => "new" end Then I get {:action=>"new"} should == {:template=>"people/new"}. Doing should_render :template => "people/new" works fine. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:32:18 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:32:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6629 ] Can't run integration tests with spec-ified rails app. Message-ID: <20061126233218.BA1F55240F42@rubyforge.org> Bugs item #6629, was opened at 2006-11-11 15:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6629&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: Can't run integration tests with spec-ified rails app. Initial Comment: After installing 'spec/rails' in an app that has rails integration tests (in test/integration), running rake test does not run the tests: $ rake test:integration (in /Users/david/projects/ruby/rspec/trunk/vendor/rspec_on_rails) /usr/local/bin/ruby -Ilib:test "/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb" $ ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 16:32 Message: I'm not entirely sure what the problem is, as far as I can tell it has something to do with the rspec stuff getting loaded. Rails unit and functional tests also aren't run - you might have used a generator that uses them. My workaround was pretty simple. I just added a flag to see if rspec shouldn't be loaded, which would be the case for unit/functional/integration. In spec_helper.rb, after the RAILS_ENV declaration, add ENV["NO_RSPEC"] = nil In test_helper.rb, after the RAILS_ENV declaration, add ENV["NO_RSPEC"] = "true" And in rspec/init.rb, change the code to if ENV['RAILS_ENV'] == 'test' && ENV['NO_RSPEC'].nil? then require 'rspec_on_rails' end Simple, works for me. Running "rake" will run unit tests, functional tests, integration tests, model specs, controller specs, and then view specs. Perfect for making sure that any generated code tests fine as well as your custom code. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6629&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:36:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:36:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6895 ] should_render :action doesn't seem to work Message-ID: <20061126233657.86E935240F42@rubyforge.org> Bugs item #6895, was opened at 2006-11-26 23:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: should_render :action doesn't seem to work Initial Comment: 0.7.3, edge rails, if I do specify "should show the form" do controller.should_render :action => "new" end Then I get {:action=>"new"} should == {:template=>"people/new"}. Doing should_render :template => "people/new" works fine. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 23:36 Message: What is in the controller code? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:40:06 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:40:06 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6896 ] should_render fails with respond_to Message-ID: <20061126234006.947B95240F42@rubyforge.org> Bugs item #6896, was opened at 2006-11-26 16:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: should_render fails with respond_to Initial Comment: Spec: specify "should show the form" do controller.should_render :template => "people/new" end Controller code: def new @person = Person.new respond_to do |format| format.html end end Failure: {:template=>"people/new"} should == {:action=>"new", :content_type=>#} ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:44:34 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:44:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6895 ] should_render :action doesn't seem to work Message-ID: <20061126234434.F32D25240F42@rubyforge.org> Bugs item #6895, was opened at 2006-11-26 16:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: should_render :action doesn't seem to work Initial Comment: 0.7.3, edge rails, if I do specify "should show the form" do controller.should_render :action => "new" end Then I get {:action=>"new"} should == {:template=>"people/new"}. Doing should_render :template => "people/new" works fine. ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2006-11-26 16:44 Message: The controller code is the very simple def new @person = Person.new end with a corresponding new.rhtml file. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 16:36 Message: What is in the controller code? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:49:00 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:49:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6895 ] should_render :action doesn't seem to work Message-ID: <20061126234900.A280B5241716@rubyforge.org> Bugs item #6895, was opened at 2006-11-26 23:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Pat Maddox (pergesu) >Assigned to: David Chelimsky (dchelimsky) Summary: should_render :action doesn't seem to work Initial Comment: 0.7.3, edge rails, if I do specify "should show the form" do controller.should_render :action => "new" end Then I get {:action=>"new"} should == {:template=>"people/new"}. Doing should_render :template => "people/new" works fine. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 23:49 Message: That's how this is supposed to work. This is really a documentation issue. The only time you would use :action is if you were redirecting to another action. Otherwise you should use :template => ... I've added a documentation request for this: http://rubyforge.org/tracker/index.php?group_id=797&atid=9738 ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 23:44 Message: The controller code is the very simple def new @person = Person.new end with a corresponding new.rhtml file. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 23:36 Message: What is in the controller code? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:49:36 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:49:36 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6896 ] should_render fails with respond_to Message-ID: <20061126234936.6C5605240F42@rubyforge.org> Bugs item #6896, was opened at 2006-11-26 23:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 >Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) >Assigned to: David Chelimsky (dchelimsky) Summary: should_render fails with respond_to Initial Comment: Spec: specify "should show the form" do controller.should_render :template => "people/new" end Controller code: def new @person = Person.new respond_to do |format| format.html end end Failure: {:template=>"people/new"} should == {:action=>"new", :content_type=>#} ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:49:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:49:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6898 ] Can we separate rspec from the plugins? Message-ID: <20061126234957.D00E15240F42@rubyforge.org> Feature Requests item #6898, was opened at 2006-11-26 16:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can we separate rspec from the plugins? Initial Comment: I'm trying to use rspec to do my rails development, and a while ago I had found a way to be able to use edge rspec and the plugin. Today I svn uped and to my surprise, the rspec code (not the plugin) ended up downloading three different versions of Rails. Is there any way we can separate the rspec code base from the plugins? If I download trunk, I just want it to be rspec itself...the Rails stuff shouldn't be under it. If I'm in a Rails project, I can install the rspec libs as a plugin, and the Rails plugin separately. Some of you may have seen my article a couple weeks ago about doing that (site is no longer up, sorry). Basically now it's a real pain to try to use edge rspec inside a Rails project. However that's the best way to make updates both to rspec itself and the plugin. If you could make it so they're separated more cleanly, I'd happily bang out Rails related bugs and RFEs as I work on my own Rails apps. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:53:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:53:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6895 ] should_render :action doesn't seem to work Message-ID: <20061126235305.389C15240F42@rubyforge.org> Bugs item #6895, was opened at 2006-11-26 16:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: David Chelimsky (dchelimsky) Summary: should_render :action doesn't seem to work Initial Comment: 0.7.3, edge rails, if I do specify "should show the form" do controller.should_render :action => "new" end Then I get {:action=>"new"} should == {:template=>"people/new"}. Doing should_render :template => "people/new" works fine. ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2006-11-26 16:53 Message: I don't like that. The current setup is to spec controllers separately from views. As such, we should specify that the request renders the result of a particular action, rather than a specific template. The template belongs to the view spec. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 16:49 Message: That's how this is supposed to work. This is really a documentation issue. The only time you would use :action is if you were redirecting to another action. Otherwise you should use :template => ... I've added a documentation request for this: http://rubyforge.org/tracker/index.php?group_id=797&atid=9738 ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 16:44 Message: The controller code is the very simple def new @person = Person.new end with a corresponding new.rhtml file. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 16:36 Message: What is in the controller code? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 From noreply at rubyforge.org Sun Nov 26 18:53:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 18:53:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6629 ] Can't run integration tests with spec-ified rails app. Message-ID: <20061126235351.2F00C5241716@rubyforge.org> Bugs item #6629, was opened at 2006-11-11 22:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6629&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: Can't run integration tests with spec-ified rails app. Initial Comment: After installing 'spec/rails' in an app that has rails integration tests (in test/integration), running rake test does not run the tests: $ rake test:integration (in /Users/david/projects/ruby/rspec/trunk/vendor/rspec_on_rails) /usr/local/bin/ruby -Ilib:test "/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb" $ ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 23:53 Message: Thanks Pat. Very helpful. I'm going to leave this open as I think it's still a bug (a workaround should not be required). Cheers! ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 23:32 Message: I'm not entirely sure what the problem is, as far as I can tell it has something to do with the rspec stuff getting loaded. Rails unit and functional tests also aren't run - you might have used a generator that uses them. My workaround was pretty simple. I just added a flag to see if rspec shouldn't be loaded, which would be the case for unit/functional/integration. In spec_helper.rb, after the RAILS_ENV declaration, add ENV["NO_RSPEC"] = nil In test_helper.rb, after the RAILS_ENV declaration, add ENV["NO_RSPEC"] = "true" And in rspec/init.rb, change the code to if ENV['RAILS_ENV'] == 'test' && ENV['NO_RSPEC'].nil? then require 'rspec_on_rails' end Simple, works for me. Running "rake" will run unit tests, functional tests, integration tests, model specs, controller specs, and then view specs. Perfect for making sure that any generated code tests fine as well as your custom code. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6629&group_id=797 From noreply at rubyforge.org Sun Nov 26 19:07:27 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 19:07:27 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6895 ] should_render :action doesn't seem to work Message-ID: <20061127000727.5D40B52417CB@rubyforge.org> Bugs item #6895, was opened at 2006-11-26 23:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: David Chelimsky (dchelimsky) Summary: should_render :action doesn't seem to work Initial Comment: 0.7.3, edge rails, if I do specify "should show the form" do controller.should_render :action => "new" end Then I get {:action=>"new"} should == {:template=>"people/new"}. Doing should_render :template => "people/new" works fine. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-27 00:07 Message: I'm sorry you don't like that, Pat. I think we have different visions of this. Let me explain where we're coming from on this. The controller's responsibility is to interact with the model and the view, and we want to be able to specify how the controller should fulfill that responsibility. Based on that thinking, the things that belong in the controller spec are interactions with the model (in the form of mock expectations set on the model) and interactions with the view (in the form of what should get assigned and what template should ultimately be rendered). Specifying that "get 'new'" causes the "new" method (or action) to be invoked is specifying that Rails works correctly, which is not something that we care about in a controller spec. Of course, there is custom routing to consider, but you can handle that with routing specs. Additionally, view specs allow you to specify what a view (template) does with the data you feed it. It has absolutely nothing to do with what controller or action invoked it. Hope this makes sense to you. Cheers, David ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 23:53 Message: I don't like that. The current setup is to spec controllers separately from views. As such, we should specify that the request renders the result of a particular action, rather than a specific template. The template belongs to the view spec. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 23:49 Message: That's how this is supposed to work. This is really a documentation issue. The only time you would use :action is if you were redirecting to another action. Otherwise you should use :template => ... I've added a documentation request for this: http://rubyforge.org/tracker/index.php?group_id=797&atid=9738 ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 23:44 Message: The controller code is the very simple def new @person = Person.new end with a corresponding new.rhtml file. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 23:36 Message: What is in the controller code? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 From noreply at rubyforge.org Sun Nov 26 19:09:24 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 19:09:24 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6895 ] should_render :action doesn't seem to work Message-ID: <20061127000924.5E93952417FF@rubyforge.org> Bugs item #6895, was opened at 2006-11-26 16:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 Category: rails plugin Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: David Chelimsky (dchelimsky) Summary: should_render :action doesn't seem to work Initial Comment: 0.7.3, edge rails, if I do specify "should show the form" do controller.should_render :action => "new" end Then I get {:action=>"new"} should == {:template=>"people/new"}. Doing should_render :template => "people/new" works fine. ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2006-11-26 17:09 Message: Alright, that makes sense to me. Just started to test views separately this morning so undoubtedly I'll be mistaken in my approach for a bit. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 17:07 Message: I'm sorry you don't like that, Pat. I think we have different visions of this. Let me explain where we're coming from on this. The controller's responsibility is to interact with the model and the view, and we want to be able to specify how the controller should fulfill that responsibility. Based on that thinking, the things that belong in the controller spec are interactions with the model (in the form of mock expectations set on the model) and interactions with the view (in the form of what should get assigned and what template should ultimately be rendered). Specifying that "get 'new'" causes the "new" method (or action) to be invoked is specifying that Rails works correctly, which is not something that we care about in a controller spec. Of course, there is custom routing to consider, but you can handle that with routing specs. Additionally, view specs allow you to specify what a view (template) does with the data you feed it. It has absolutely nothing to do with what controller or action invoked it. Hope this makes sense to you. Cheers, David ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 16:53 Message: I don't like that. The current setup is to spec controllers separately from views. As such, we should specify that the request renders the result of a particular action, rather than a specific template. The template belongs to the view spec. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 16:49 Message: That's how this is supposed to work. This is really a documentation issue. The only time you would use :action is if you were redirecting to another action. Otherwise you should use :template => ... I've added a documentation request for this: http://rubyforge.org/tracker/index.php?group_id=797&atid=9738 ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 16:44 Message: The controller code is the very simple def new @person = Person.new end with a corresponding new.rhtml file. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 16:36 Message: What is in the controller code? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6895&group_id=797 From noreply at rubyforge.org Sun Nov 26 19:13:40 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 19:13:40 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6898 ] Can we separate rspec from the plugins? Message-ID: <20061127001341.1EB5952417CC@rubyforge.org> Feature Requests item #6898, was opened at 2006-11-26 23:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can we separate rspec from the plugins? Initial Comment: I'm trying to use rspec to do my rails development, and a while ago I had found a way to be able to use edge rspec and the plugin. Today I svn uped and to my surprise, the rspec code (not the plugin) ended up downloading three different versions of Rails. Is there any way we can separate the rspec code base from the plugins? If I download trunk, I just want it to be rspec itself...the Rails stuff shouldn't be under it. If I'm in a Rails project, I can install the rspec libs as a plugin, and the Rails plugin separately. Some of you may have seen my article a couple weeks ago about doing that (site is no longer up, sorry). Basically now it's a real pain to try to use edge rspec inside a Rails project. However that's the best way to make updates both to rspec itself and the plugin. If you could make it so they're separated more cleanly, I'd happily bang out Rails related bugs and RFEs as I work on my own Rails apps. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-27 00:13 Message: Absolutely! We've been wanting to restructure things and this is one of the issues under discussion. We'll address this soon. When we're ready to, there will be an email to the list in advance so that those who do prefer to work from source won't be all screwed up by it. And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 From noreply at rubyforge.org Sun Nov 26 19:18:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 19:18:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6898 ] Can we separate rspec from the plugins? Message-ID: <20061127001850.D8B6C52417CB@rubyforge.org> Feature Requests item #6898, was opened at 2006-11-26 16:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can we separate rspec from the plugins? Initial Comment: I'm trying to use rspec to do my rails development, and a while ago I had found a way to be able to use edge rspec and the plugin. Today I svn uped and to my surprise, the rspec code (not the plugin) ended up downloading three different versions of Rails. Is there any way we can separate the rspec code base from the plugins? If I download trunk, I just want it to be rspec itself...the Rails stuff shouldn't be under it. If I'm in a Rails project, I can install the rspec libs as a plugin, and the Rails plugin separately. Some of you may have seen my article a couple weeks ago about doing that (site is no longer up, sorry). Basically now it's a real pain to try to use edge rspec inside a Rails project. However that's the best way to make updates both to rspec itself and the plugin. If you could make it so they're separated more cleanly, I'd happily bang out Rails related bugs and RFEs as I work on my own Rails apps. ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2006-11-26 17:18 Message: "And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well." That's what I meant by bang out bugs and RFEs :) I'll go through the list and write patches, as well as come up with whatever other patches I need as I write my Rails app. Just kinda tough with the current structure...any timeline on when things will be cleaner? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 17:13 Message: Absolutely! We've been wanting to restructure things and this is one of the issues under discussion. We'll address this soon. When we're ready to, there will be an email to the list in advance so that those who do prefer to work from source won't be all screwed up by it. And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 From noreply at rubyforge.org Sun Nov 26 19:20:11 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 19:20:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6896 ] should_render fails with respond_to Message-ID: <20061127002011.A326552417CB@rubyforge.org> Bugs item #6896, was opened at 2006-11-26 18:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: David Chelimsky (dchelimsky) Summary: should_render fails with respond_to Initial Comment: Spec: specify "should show the form" do controller.should_render :template => "people/new" end Controller code: def new @person = Person.new respond_to do |format| format.html end end Failure: {:template=>"people/new"} should == {:action=>"new", :content_type=>#} ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 19:20 Message: versions???? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 From noreply at rubyforge.org Sun Nov 26 19:20:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 19:20:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6896 ] should_render fails with respond_to Message-ID: <20061127002050.3AD8F52417CB@rubyforge.org> Bugs item #6896, was opened at 2006-11-26 16:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: David Chelimsky (dchelimsky) Summary: should_render fails with respond_to Initial Comment: Spec: specify "should show the form" do controller.should_render :template => "people/new" end Controller code: def new @person = Person.new respond_to do |format| format.html end end Failure: {:template=>"people/new"} should == {:action=>"new", :content_type=>#} ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2006-11-26 17:20 Message: Edge rails, 0.7.3 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 17:20 Message: versions???? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 From noreply at rubyforge.org Sun Nov 26 19:40:34 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 19:40:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6898 ] Can we separate rspec from the plugins? Message-ID: <20061127004034.526A252417C5@rubyforge.org> Feature Requests item #6898, was opened at 2006-11-26 18:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can we separate rspec from the plugins? Initial Comment: I'm trying to use rspec to do my rails development, and a while ago I had found a way to be able to use edge rspec and the plugin. Today I svn uped and to my surprise, the rspec code (not the plugin) ended up downloading three different versions of Rails. Is there any way we can separate the rspec code base from the plugins? If I download trunk, I just want it to be rspec itself...the Rails stuff shouldn't be under it. If I'm in a Rails project, I can install the rspec libs as a plugin, and the Rails plugin separately. Some of you may have seen my article a couple weeks ago about doing that (site is no longer up, sorry). Basically now it's a real pain to try to use edge rspec inside a Rails project. However that's the best way to make updates both to rspec itself and the plugin. If you could make it so they're separated more cleanly, I'd happily bang out Rails related bugs and RFEs as I work on my own Rails apps. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 19:40 Message: Reorganising things is the kind of thing that is hard to submit a patch for. It's just a bunch of svn mv (plus a little rake hacking). Let's discuss the proposed layout here. This is my initial suggestion (everything is under trunk) Rakefile # Delegates to sub Rakefiles - for running *all* specs rspec/init.rb # The core - requires the three subprojects, each of which have their own lib and spec dir rspec/expectations rspec/context_runner rspec/mocks jruby/ RSpec.tmbundle/ rspec_on_rails/ rspec_on_rails_demo/ # Could pull in rspec_on_rails via svn:external selenium/ watir/ This organisation would allow Rails projects to install RSpec as 2 Rails plugins: rspec and rspec_on_rails WDYT? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 19:18 Message: "And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well." That's what I meant by bang out bugs and RFEs :) I'll go through the list and write patches, as well as come up with whatever other patches I need as I write my Rails app. Just kinda tough with the current structure...any timeline on when things will be cleaner? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 19:13 Message: Absolutely! We've been wanting to restructure things and this is one of the issues under discussion. We'll address this soon. When we're ready to, there will be an email to the list in advance so that those who do prefer to work from source won't be all screwed up by it. And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 From noreply at rubyforge.org Sun Nov 26 19:56:46 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 19:56:46 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6898 ] Can we separate rspec from the plugins? Message-ID: <20061127005646.A406952417C5@rubyforge.org> Feature Requests item #6898, was opened at 2006-11-26 16:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can we separate rspec from the plugins? Initial Comment: I'm trying to use rspec to do my rails development, and a while ago I had found a way to be able to use edge rspec and the plugin. Today I svn uped and to my surprise, the rspec code (not the plugin) ended up downloading three different versions of Rails. Is there any way we can separate the rspec code base from the plugins? If I download trunk, I just want it to be rspec itself...the Rails stuff shouldn't be under it. If I'm in a Rails project, I can install the rspec libs as a plugin, and the Rails plugin separately. Some of you may have seen my article a couple weeks ago about doing that (site is no longer up, sorry). Basically now it's a real pain to try to use edge rspec inside a Rails project. However that's the best way to make updates both to rspec itself and the plugin. If you could make it so they're separated more cleanly, I'd happily bang out Rails related bugs and RFEs as I work on my own Rails apps. ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2006-11-26 17:56 Message: On top of svn mv and rake hacking, you'll have to edit all the files that "require 'some_other_file'" to use relative paths. When I was splitting stuff out on my own that's what I had to do...but it's not too bad. The proposed structure is basically exactly what I'd like to see. Makes it really easy to include just what you want, which of course makes it easy to make changes. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 17:40 Message: Reorganising things is the kind of thing that is hard to submit a patch for. It's just a bunch of svn mv (plus a little rake hacking). Let's discuss the proposed layout here. This is my initial suggestion (everything is under trunk) Rakefile # Delegates to sub Rakefiles - for running *all* specs rspec/init.rb # The core - requires the three subprojects, each of which have their own lib and spec dir rspec/expectations rspec/context_runner rspec/mocks jruby/ RSpec.tmbundle/ rspec_on_rails/ rspec_on_rails_demo/ # Could pull in rspec_on_rails via svn:external selenium/ watir/ This organisation would allow Rails projects to install RSpec as 2 Rails plugins: rspec and rspec_on_rails WDYT? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 17:18 Message: "And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well." That's what I meant by bang out bugs and RFEs :) I'll go through the list and write patches, as well as come up with whatever other patches I need as I write my Rails app. Just kinda tough with the current structure...any timeline on when things will be cleaner? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 17:13 Message: Absolutely! We've been wanting to restructure things and this is one of the issues under discussion. We'll address this soon. When we're ready to, there will be an email to the list in advance so that those who do prefer to work from source won't be all screwed up by it. And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 From noreply at rubyforge.org Sun Nov 26 20:03:59 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 20:03:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6898 ] Can we separate rspec from the plugins? Message-ID: <20061127010359.ECB025241814@rubyforge.org> Feature Requests item #6898, was opened at 2006-11-26 23:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can we separate rspec from the plugins? Initial Comment: I'm trying to use rspec to do my rails development, and a while ago I had found a way to be able to use edge rspec and the plugin. Today I svn uped and to my surprise, the rspec code (not the plugin) ended up downloading three different versions of Rails. Is there any way we can separate the rspec code base from the plugins? If I download trunk, I just want it to be rspec itself...the Rails stuff shouldn't be under it. If I'm in a Rails project, I can install the rspec libs as a plugin, and the Rails plugin separately. Some of you may have seen my article a couple weeks ago about doing that (site is no longer up, sorry). Basically now it's a real pain to try to use edge rspec inside a Rails project. However that's the best way to make updates both to rspec itself and the plugin. If you could make it so they're separated more cleanly, I'd happily bang out Rails related bugs and RFEs as I work on my own Rails apps. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-27 01:03 Message: One thing about separating rspec_on_rails and rspec_on_rails_demo. Right now, the specs inside rspec_on_rails won't work w/o the demo in place (because the demo also houses files specifically present for the specs). So, initially, we'd run the specs via the demo, but eventually we want to make the rspec_on_rails tree be complete (i.e. you can run all the specs within that tree). Make sense? Otherwise, this sounds good. I think we should plan a time to do this. Aslak - do you want to drive it? Thanks, David ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-27 00:56 Message: On top of svn mv and rake hacking, you'll have to edit all the files that "require 'some_other_file'" to use relative paths. When I was splitting stuff out on my own that's what I had to do...but it's not too bad. The proposed structure is basically exactly what I'd like to see. Makes it really easy to include just what you want, which of course makes it easy to make changes. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-27 00:40 Message: Reorganising things is the kind of thing that is hard to submit a patch for. It's just a bunch of svn mv (plus a little rake hacking). Let's discuss the proposed layout here. This is my initial suggestion (everything is under trunk) Rakefile # Delegates to sub Rakefiles - for running *all* specs rspec/init.rb # The core - requires the three subprojects, each of which have their own lib and spec dir rspec/expectations rspec/context_runner rspec/mocks jruby/ RSpec.tmbundle/ rspec_on_rails/ rspec_on_rails_demo/ # Could pull in rspec_on_rails via svn:external selenium/ watir/ This organisation would allow Rails projects to install RSpec as 2 Rails plugins: rspec and rspec_on_rails WDYT? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-27 00:18 Message: "And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well." That's what I meant by bang out bugs and RFEs :) I'll go through the list and write patches, as well as come up with whatever other patches I need as I write my Rails app. Just kinda tough with the current structure...any timeline on when things will be cleaner? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-27 00:13 Message: Absolutely! We've been wanting to restructure things and this is one of the issues under discussion. We'll address this soon. When we're ready to, there will be an email to the list in advance so that those who do prefer to work from source won't be all screwed up by it. And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 From noreply at rubyforge.org Sun Nov 26 20:18:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 20:18:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6898 ] Can we separate rspec from the plugins? Message-ID: <20061127011805.7F4D2524182D@rubyforge.org> Feature Requests item #6898, was opened at 2006-11-26 18:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can we separate rspec from the plugins? Initial Comment: I'm trying to use rspec to do my rails development, and a while ago I had found a way to be able to use edge rspec and the plugin. Today I svn uped and to my surprise, the rspec code (not the plugin) ended up downloading three different versions of Rails. Is there any way we can separate the rspec code base from the plugins? If I download trunk, I just want it to be rspec itself...the Rails stuff shouldn't be under it. If I'm in a Rails project, I can install the rspec libs as a plugin, and the Rails plugin separately. Some of you may have seen my article a couple weeks ago about doing that (site is no longer up, sorry). Basically now it's a real pain to try to use edge rspec inside a Rails project. However that's the best way to make updates both to rspec itself and the plugin. If you could make it so they're separated more cleanly, I'd happily bang out Rails related bugs and RFEs as I work on my own Rails apps. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 20:18 Message: Ok, I can drive it. I'll probably do it on a branch. Does anyone know if svn handles a merge back to trunk when files have been moved on the branch and modified on the trunk in the meanwhile? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 20:03 Message: One thing about separating rspec_on_rails and rspec_on_rails_demo. Right now, the specs inside rspec_on_rails won't work w/o the demo in place (because the demo also houses files specifically present for the specs). So, initially, we'd run the specs via the demo, but eventually we want to make the rspec_on_rails tree be complete (i.e. you can run all the specs within that tree). Make sense? Otherwise, this sounds good. I think we should plan a time to do this. Aslak - do you want to drive it? Thanks, David ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 19:56 Message: On top of svn mv and rake hacking, you'll have to edit all the files that "require 'some_other_file'" to use relative paths. When I was splitting stuff out on my own that's what I had to do...but it's not too bad. The proposed structure is basically exactly what I'd like to see. Makes it really easy to include just what you want, which of course makes it easy to make changes. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 19:40 Message: Reorganising things is the kind of thing that is hard to submit a patch for. It's just a bunch of svn mv (plus a little rake hacking). Let's discuss the proposed layout here. This is my initial suggestion (everything is under trunk) Rakefile # Delegates to sub Rakefiles - for running *all* specs rspec/init.rb # The core - requires the three subprojects, each of which have their own lib and spec dir rspec/expectations rspec/context_runner rspec/mocks jruby/ RSpec.tmbundle/ rspec_on_rails/ rspec_on_rails_demo/ # Could pull in rspec_on_rails via svn:external selenium/ watir/ This organisation would allow Rails projects to install RSpec as 2 Rails plugins: rspec and rspec_on_rails WDYT? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 19:18 Message: "And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well." That's what I meant by bang out bugs and RFEs :) I'll go through the list and write patches, as well as come up with whatever other patches I need as I write my Rails app. Just kinda tough with the current structure...any timeline on when things will be cleaner? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 19:13 Message: Absolutely! We've been wanting to restructure things and this is one of the issues under discussion. We'll address this soon. When we're ready to, there will be an email to the list in advance so that those who do prefer to work from source won't be all screwed up by it. And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 From noreply at rubyforge.org Sun Nov 26 20:34:01 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 20:34:01 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6898 ] Can we separate rspec from the plugins? Message-ID: <20061127013401.33890524182D@rubyforge.org> Feature Requests item #6898, was opened at 2006-11-26 16:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can we separate rspec from the plugins? Initial Comment: I'm trying to use rspec to do my rails development, and a while ago I had found a way to be able to use edge rspec and the plugin. Today I svn uped and to my surprise, the rspec code (not the plugin) ended up downloading three different versions of Rails. Is there any way we can separate the rspec code base from the plugins? If I download trunk, I just want it to be rspec itself...the Rails stuff shouldn't be under it. If I'm in a Rails project, I can install the rspec libs as a plugin, and the Rails plugin separately. Some of you may have seen my article a couple weeks ago about doing that (site is no longer up, sorry). Basically now it's a real pain to try to use edge rspec inside a Rails project. However that's the best way to make updates both to rspec itself and the plugin. If you could make it so they're separated more cleanly, I'd happily bang out Rails related bugs and RFEs as I work on my own Rails apps. ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2006-11-26 18:34 Message: iirc, it won't. When you do the mv it simply does an add and delete, and as far as svn is concerned there is no link between the files. So basically if you're planning on doing this, it'd be best for everyone else to freeze until you get it done. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 18:18 Message: Ok, I can drive it. I'll probably do it on a branch. Does anyone know if svn handles a merge back to trunk when files have been moved on the branch and modified on the trunk in the meanwhile? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 18:03 Message: One thing about separating rspec_on_rails and rspec_on_rails_demo. Right now, the specs inside rspec_on_rails won't work w/o the demo in place (because the demo also houses files specifically present for the specs). So, initially, we'd run the specs via the demo, but eventually we want to make the rspec_on_rails tree be complete (i.e. you can run all the specs within that tree). Make sense? Otherwise, this sounds good. I think we should plan a time to do this. Aslak - do you want to drive it? Thanks, David ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 17:56 Message: On top of svn mv and rake hacking, you'll have to edit all the files that "require 'some_other_file'" to use relative paths. When I was splitting stuff out on my own that's what I had to do...but it's not too bad. The proposed structure is basically exactly what I'd like to see. Makes it really easy to include just what you want, which of course makes it easy to make changes. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 17:40 Message: Reorganising things is the kind of thing that is hard to submit a patch for. It's just a bunch of svn mv (plus a little rake hacking). Let's discuss the proposed layout here. This is my initial suggestion (everything is under trunk) Rakefile # Delegates to sub Rakefiles - for running *all* specs rspec/init.rb # The core - requires the three subprojects, each of which have their own lib and spec dir rspec/expectations rspec/context_runner rspec/mocks jruby/ RSpec.tmbundle/ rspec_on_rails/ rspec_on_rails_demo/ # Could pull in rspec_on_rails via svn:external selenium/ watir/ This organisation would allow Rails projects to install RSpec as 2 Rails plugins: rspec and rspec_on_rails WDYT? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 17:18 Message: "And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well." That's what I meant by bang out bugs and RFEs :) I'll go through the list and write patches, as well as come up with whatever other patches I need as I write my Rails app. Just kinda tough with the current structure...any timeline on when things will be cleaner? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 17:13 Message: Absolutely! We've been wanting to restructure things and this is one of the issues under discussion. We'll address this soon. When we're ready to, there will be an email to the list in advance so that those who do prefer to work from source won't be all screwed up by it. And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 From noreply at rubyforge.org Sun Nov 26 20:58:56 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 20:58:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6898 ] Can we separate rspec from the plugins? Message-ID: <20061127015856.27A57524182D@rubyforge.org> Feature Requests item #6898, was opened at 2006-11-26 18:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can we separate rspec from the plugins? Initial Comment: I'm trying to use rspec to do my rails development, and a while ago I had found a way to be able to use edge rspec and the plugin. Today I svn uped and to my surprise, the rspec code (not the plugin) ended up downloading three different versions of Rails. Is there any way we can separate the rspec code base from the plugins? If I download trunk, I just want it to be rspec itself...the Rails stuff shouldn't be under it. If I'm in a Rails project, I can install the rspec libs as a plugin, and the Rails plugin separately. Some of you may have seen my article a couple weeks ago about doing that (site is no longer up, sorry). Basically now it's a real pain to try to use edge rspec inside a Rails project. However that's the best way to make updates both to rspec itself and the plugin. If you could make it so they're separated more cleanly, I'd happily bang out Rails related bugs and RFEs as I work on my own Rails apps. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 20:58 Message: The only thing here is the spec script. If a Rails app includes RSpec as a plugin, then the spec command will be deep down in vendor/plugins/rspec/bin/spec That's a bit clunky to run from the commandline. Perhaps script/generate rspec should create a script/spec command if vendor/plugins/rspec/bin/spec is present? script/spec would just load vendor/plugins/rspec/bin/spec WDYT? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 20:34 Message: iirc, it won't. When you do the mv it simply does an add and delete, and as far as svn is concerned there is no link between the files. So basically if you're planning on doing this, it'd be best for everyone else to freeze until you get it done. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 20:18 Message: Ok, I can drive it. I'll probably do it on a branch. Does anyone know if svn handles a merge back to trunk when files have been moved on the branch and modified on the trunk in the meanwhile? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 20:03 Message: One thing about separating rspec_on_rails and rspec_on_rails_demo. Right now, the specs inside rspec_on_rails won't work w/o the demo in place (because the demo also houses files specifically present for the specs). So, initially, we'd run the specs via the demo, but eventually we want to make the rspec_on_rails tree be complete (i.e. you can run all the specs within that tree). Make sense? Otherwise, this sounds good. I think we should plan a time to do this. Aslak - do you want to drive it? Thanks, David ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 19:56 Message: On top of svn mv and rake hacking, you'll have to edit all the files that "require 'some_other_file'" to use relative paths. When I was splitting stuff out on my own that's what I had to do...but it's not too bad. The proposed structure is basically exactly what I'd like to see. Makes it really easy to include just what you want, which of course makes it easy to make changes. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 19:40 Message: Reorganising things is the kind of thing that is hard to submit a patch for. It's just a bunch of svn mv (plus a little rake hacking). Let's discuss the proposed layout here. This is my initial suggestion (everything is under trunk) Rakefile # Delegates to sub Rakefiles - for running *all* specs rspec/init.rb # The core - requires the three subprojects, each of which have their own lib and spec dir rspec/expectations rspec/context_runner rspec/mocks jruby/ RSpec.tmbundle/ rspec_on_rails/ rspec_on_rails_demo/ # Could pull in rspec_on_rails via svn:external selenium/ watir/ This organisation would allow Rails projects to install RSpec as 2 Rails plugins: rspec and rspec_on_rails WDYT? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-26 19:18 Message: "And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well." That's what I meant by bang out bugs and RFEs :) I'll go through the list and write patches, as well as come up with whatever other patches I need as I write my Rails app. Just kinda tough with the current structure...any timeline on when things will be cleaner? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-26 19:13 Message: Absolutely! We've been wanting to restructure things and this is one of the issues under discussion. We'll address this soon. When we're ready to, there will be an email to the list in advance so that those who do prefer to work from source won't be all screwed up by it. And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 From noreply at rubyforge.org Sun Nov 26 21:12:56 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 21:12:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6903 ] Rendering a partial in a view makes the view spec blow up Message-ID: <20061127021256.79BA85241843@rubyforge.org> Bugs item #6903, was opened at 2006-11-26 19:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6903&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Rendering a partial in a view makes the view spec blow up Initial Comment: In a view spec, say you call render "people/show" and the show.rhtml file consists solely of <%= render :partial => "person", :object => @person %> the spec blows up with No rhtml, rxml, rjs or delegate template found for spec/rails/view_spec/_person in /Users/pergesu/work/givelist/trunk/config/../app/views Changing the render call to be render :partial => "people/person", :object => @person works fine. So the view spec is making something relative to the root views dir, when *I think* it should probably be relative to people in this case. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6903&group_id=797 From noreply at rubyforge.org Sun Nov 26 22:41:45 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 26 Nov 2006 22:41:45 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated Message-ID: <20061127034146.20CDCA970003@rubyforge.org> Bugs item #6905, was opened at 2006-11-26 20:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6905&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Mocking rails associations where the association is validated Initial Comment: Take the following model class Person < ActiveRecord::Base belongs_to :user validates_presence_of :name, :user end the following spec specify "should create a new person" do @u.should_receive(:to_param).and_return("pat") @u.should_receive(:people).and_return([]) @before_count = Person.count post :create, :user_id => "pat", :person => { :name => "BJ" } Person.should_have(@before_count + 1).records end and the following action def create @user = User.find_by_login params[:user_id] @person = Person.new params[:person] @user.people << @person redirect_to person_path(@user, @person) end The spec fails because the Person can't be saved. The Person can't be saved because it fails the validates_presence_of :user. In Rails, the collection is a proxy rather than simply an array, and the << method is written such that it would actually set @person.user in the above code. A simple array of course doesn't do that. I've got an idea to handle this, which involves writing a basic class that does all the setting, and returning that for people instead of an array. That ought to work. The code behaves as expected, but the spec does not. The other way you would do this association is to do @person.user = @user but Rails does some type checking here, and you get User expected, got Spec::Mocks::Mock No problem, just do @user.should_receive(:class).and_return(User) BUT you get User expected, got User hrm. I made it return the string "User" instead of the class and got the same thing. I'm going to work on a rails-like collection class, since that's what I'm most interested in at the moment. Not sure what to do about the strange "User expected, got User" when assigning the value of a belongs_to. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6905&group_id=797 From noreply at rubyforge.org Mon Nov 27 01:33:21 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Nov 2006 01:33:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated Message-ID: <20061127063321.D84C05240C65@rubyforge.org> Bugs item #6905, was opened at 2006-11-27 03:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6905&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Pat Maddox (pergesu) >Assigned to: David Chelimsky (dchelimsky) Summary: Mocking rails associations where the association is validated Initial Comment: Take the following model class Person < ActiveRecord::Base belongs_to :user validates_presence_of :name, :user end the following spec specify "should create a new person" do @u.should_receive(:to_param).and_return("pat") @u.should_receive(:people).and_return([]) @before_count = Person.count post :create, :user_id => "pat", :person => { :name => "BJ" } Person.should_have(@before_count + 1).records end and the following action def create @user = User.find_by_login params[:user_id] @person = Person.new params[:person] @user.people << @person redirect_to person_path(@user, @person) end The spec fails because the Person can't be saved. The Person can't be saved because it fails the validates_presence_of :user. In Rails, the collection is a proxy rather than simply an array, and the << method is written such that it would actually set @person.user in the above code. A simple array of course doesn't do that. I've got an idea to handle this, which involves writing a basic class that does all the setting, and returning that for people instead of an array. That ought to work. The code behaves as expected, but the spec does not. The other way you would do this association is to do @person.user = @user but Rails does some type checking here, and you get User expected, got Spec::Mocks::Mock No problem, just do @user.should_receive(:class).and_return(User) BUT you get User expected, got User hrm. I made it return the string "User" instead of the class and got the same thing. I'm going to work on a rails-like collection class, since that's what I'm most interested in at the moment. Not sure what to do about the strange "User expected, got User" when assigning the value of a belongs_to. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-27 06:33 Message: This is not an RSpec bug. You are choosing to return an Array instead of the Rails proxy (or a mock of it) which is how Rails behaves. I'm going to follow up with this on the mailing list. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6905&group_id=797 From dchelimsky at gmail.com Mon Nov 27 01:40:23 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 27 Nov 2006 00:40:23 -0600 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <20061127063321.D84C05240C65@rubyforge.org> References: <20061127063321.D84C05240C65@rubyforge.org> Message-ID: <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> One goal of splitting specs into model, view, controller specs is to decouple the underlying AR behaviour from what you specify in a controller or view spec. What I would do in the example that Pat provided is specify validations in the model specs and then mock out the models in the controller specs. Given your current implementation, you could have the following spec: specify "should create a new Person and stick it in the users people" do mock_user = mock("user") mock_person = mock("person") mock_people = mock("user people") mock_user.should_receive(:people).and_return(mock_people) mock_people.should_receive(:<<).with(mock_person) User.should_receive(:find_by_login).with("pat").and_return(mock_user) Person.should_receive(:new).with(:name => "BJ").and_return(mock_person) post :create, :user_id => "pat", :person => { :name => "BJ" } end If that seems like a lot of mocking to you (it does to me), that's because adding something to @user.people in this context is a violation of Tell, Don't Ask and also smells like Feature Envy (when one object operates on the data of another). This could be solved by adding an add_person method to User. Now your controller spec could look like this: specify "should create a new Person and stick it in the users people" do mock_user = mock("user") mock_person = mock("person") mock_user.should_receive(:add_person).with(mock_person) User.should_receive(:find_by_login).with("pat").and_return(mock_user) Person.should_receive(:new).with(:name => "BJ").and_return(mock_person) post :create, :user_id => "pat", :person => { :name => "BJ" } end and the create method: def create @user = User.find_by_login params[:user_id] @person = Person.new params[:person] @user.add_person @person redirect_to person_path(@user, @person) end Small change to the create method. Not so small implications in terms of decoupling the design. No intent to dis your design here, Pat. I've certainly done much worse that that along the way! The problem is that ActiveRecord encourages this sort of highly coupled design, and the problems that go along with it (like having to do many layers of mocking in your specs). It's one of those situations in which we get so much good from AR that we have to live w/ the design problems it encourages, and try to address them through discussion and education. And that's why I believe so strongly in the approach we're trying to take w/ the rails plugin. Cheers, David ---------- Forwarded message ---------- From: noreply at rubyforge.org Date: Nov 27, 2006 12:33 AM Subject: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated To: noreply at rubyforge.org Bugs item #6905, was opened at 2006-11-27 03:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6905&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Pat Maddox (pergesu) >Assigned to: David Chelimsky (dchelimsky) Summary: Mocking rails associations where the association is validated Initial Comment: Take the following model class Person < ActiveRecord::Base belongs_to :user validates_presence_of :name, :user end the following spec specify "should create a new person" do @u.should_receive(:to_param).and_return("pat") @u.should_receive(:people).and_return([]) @before_count = Person.count post :create, :user_id => "pat", :person => { :name => "BJ" } Person.should_have(@before_count + 1).records end and the following action def create @user = User.find_by_login params[:user_id] @person = Person.new params[:person] @user.people << @person redirect_to person_path(@user, @person) end The spec fails because the Person can't be saved. The Person can't be saved because it fails the validates_presence_of :user. In Rails, the collection is a proxy rather than simply an array, and the << method is written such that it would actually set @person.user in the above code. A simple array of course doesn't do that. I've got an idea to handle this, which involves writing a basic class that does all the setting, and returning that for people instead of an array. That ought to work. The code behaves as expected, but the spec does not. The other way you would do this association is to do @person.user = @user but Rails does some type checking here, and you get User expected, got Spec::Mocks::Mock No problem, just do @user.should_receive(:class).and_return(User) BUT you get User expected, got User hrm. I made it return the string "User" instead of the class and got the same thing. I'm going to work on a rails-like collection class, since that's what I'm most interested in at the moment. Not sure what to do about the strange "User expected, got User" when assigning the value of a belongs_to. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-27 06:33 Message: This is not an RSpec bug. You are choosing to return an Array instead of the Rails proxy (or a mock of it) which is how Rails behaves. I'm going to follow up with this on the mailing list. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6905&group_id=797 From pergesu at gmail.com Mon Nov 27 03:53:10 2006 From: pergesu at gmail.com (Pat Maddox) Date: Mon, 27 Nov 2006 01:53:10 -0700 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> Message-ID: <810a540e0611270053s5a8aa82y8225f0150caccacb@mail.gmail.com> Hey David, Thanks for the info. I know that it wasn't a bug in RSpec at all...I was just describing something that I wanted to do, but couldn't at the time. I posted it to say, "Hey this is my problem, I'm working on a solution," and perhaps spark discussion if warranted. As I mentioned in the report, I knew that the problem was I was using an array, and actually I began writing a class that would act like the Rails collection class for me. Then my girlfriend interrupted me... Glad she did :) Had another aha moment reading your post. On 11/26/06, David Chelimsky wrote: > One goal of splitting specs into model, view, controller specs is to > decouple the underlying AR behaviour from what you specify in a > controller or view spec. > > What I would do in the example that Pat provided is specify > validations in the model specs and then mock out the models in the > controller specs. Given your current implementation, you could have > the following spec: > > specify "should create a new Person and stick it in the users people" do > mock_user = mock("user") > mock_person = mock("person") > mock_people = mock("user people") > mock_user.should_receive(:people).and_return(mock_people) > mock_people.should_receive(:<<).with(mock_person) > > User.should_receive(:find_by_login).with("pat").and_return(mock_user) > Person.should_receive(:new).with(:name => "BJ").and_return(mock_person) > > post :create, :user_id => "pat", :person => { :name => "BJ" } > end > > If that seems like a lot of mocking to you (it does to me), that's > because adding something to @user.people in this context is a > violation of Tell, Don't Ask and also smells like Feature Envy (when > one object operates on the data of another). I see what you mean. At first I thought it wasn't a big deal, because we're just telling the people collection to add another person. But really, we're asking for the people collection, and then telling it to do something, when we're really interacting with the user object. There's no need to know that there's a collection of people. Interestingly, if I were to see people = user.people people << person I'd instantly identify that as a code smell. Perhaps it all being on the same line and the syntactic sugar of << hid it from me. > This could be solved by > adding an add_person method to User. Now your controller spec could > look like this: > > specify "should create a new Person and stick it in the users people" do > mock_user = mock("user") > mock_person = mock("person") > mock_user.should_receive(:add_person).with(mock_person) > > User.should_receive(:find_by_login).with("pat").and_return(mock_user) > Person.should_receive(:new).with(:name => "BJ").and_return(mock_person) > > post :create, :user_id => "pat", :person => { :name => "BJ" } > end > > and the create method: > > def create > @user = User.find_by_login params[:user_id] > @person = Person.new params[:person] > @user.add_person @person > redirect_to person_path(@user, @person) > end > > Small change to the create method. Not so small implications in terms > of decoupling the design. > > No intent to dis your design here, Pat. I've certainly done much worse > that that along the way! The problem is that ActiveRecord encourages > this sort of highly coupled design, and the problems that go along > with it (like having to do many layers of mocking in your specs). It's > one of those situations in which we get so much good from AR that we > have to live w/ the design problems it encourages, and try to address > them through discussion and education. And that's why I believe so > strongly in the approach we're trying to take w/ the rails plugin. No problem at all, I'm glad you brought this up. In other languages or frameworks I would create an add_person method...but for some reason this case didn't jump out at me as breaking encapsulation. Of course it'll be easier to recognize and avoid the problem in the future though. So I think I've learned a lesson here...if it's hard for me to do something, it's likely a deficiency in my design. I couldn't get the expectations to work like I wanted, because I was using mocks wrong, because my design was too tightly coupled. Thank you very much for taking the time to discuss this. I'm looking forward to making more (different!) mistakes :) Pat From noreply at rubyforge.org Mon Nov 27 03:56:49 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Nov 2006 03:56:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6903 ] Rendering a partial in a view makes the view spec blow up Message-ID: <20061127085649.9F34B524152C@rubyforge.org> Bugs item #6903, was opened at 2006-11-26 21:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6903&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Rendering a partial in a view makes the view spec blow up Initial Comment: In a view spec, say you call render "people/show" and the show.rhtml file consists solely of <%= render :partial => "person", :object => @person %> the spec blows up with No rhtml, rxml, rjs or delegate template found for spec/rails/view_spec/_person in /Users/pergesu/work/givelist/trunk/config/../app/views Changing the render call to be render :partial => "people/person", :object => @person works fine. So the view spec is making something relative to the root views dir, when *I think* it should probably be relative to people in this case. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-27 03:56 Message: Is there any chance you could reproduce this in the demo app and attach a patch so I can reproduce this easily? It would also be helpful to know what Rails/Rspec version/revision you're using. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6903&group_id=797 From pergesu at gmail.com Mon Nov 27 04:29:27 2006 From: pergesu at gmail.com (Pat Maddox) Date: Mon, 27 Nov 2006 02:29:27 -0700 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> Message-ID: <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> On 11/26/06, David Chelimsky wrote: > This could be solved by > adding an add_person method to User. Now your controller spec could > look like this: > > specify "should create a new Person and stick it in the users people" do > mock_user = mock("user") > mock_person = mock("person") > mock_user.should_receive(:add_person).with(mock_person) > > User.should_receive(:find_by_login).with("pat").and_return(mock_user) > Person.should_receive(:new).with(:name => "BJ").and_return(mock_person) > > post :create, :user_id => "pat", :person => { :name => "BJ" } > end If I want to specify the redirect, would I do specify "should redirect to the new person" do mock_user = mock("user", :null_object => true) mock_person = mock("person") mock_user.should_receive(:to_param).and_return("pat") mock_person.should_receive(:to_param).and_return(1) User.should_receive(:find_by_login).with("pat").and_return(mock_user) Person.should_receive(:new).with("name" => "BJ").and_return(mock_person) controller.should_redirect_to :action => "show", :user_id => "pat", :id => 1 post :create, :user_id => "pat", :person => { :name => "BJ" } end or should I just include the controller.should_redirect_to in the first spec I showed? I try to stick to Dave Astels' "One Expectation Per Example" guideline...and I usually do fine when writing model code, or standalone classes, but obviously neither of these examples follows that at all closely. Is it even possible to follow it with controller specs? I'm trying to get some heuristics for determining how much is too much in a single spec. In my example, redirecting behavior doesn't have anything to do with the behavior of adding a user, so I think they should be split out. But then there's a lot of code in the second spec that has nothing to do with the redirect behavior (User.find and Person.new certainly don't have anything to do with that). Is that just a consequence of all that goes on in an action, or is it a sign that there's room to refactor? Pat From pergesu at gmail.com Mon Nov 27 04:54:53 2006 From: pergesu at gmail.com (Pat Maddox) Date: Mon, 27 Nov 2006 02:54:53 -0700 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> Message-ID: <810a540e0611270154x162d61byb16ed1401997e455@mail.gmail.com> Another question :) When I first wrote the add_person method, my spec looked like this: specify "should accept a new person" do @user.people.size.should_be 0 @user.add_person Person.new @user.people.size.should_be 1 end That works, of course, and lets me infer that I have the new user. However I think it's ugly that I'm accessing people to verify something about the user... So then I decided to change it to this: specify "should accept a new person" do mock_person = mock("person") mock_people = mock("people") @user.should_receive(:people).and_return(mock_people) mock_people.should_receive(:<<).with(mock_person) @user.add_person mock_person end That feels like the more RSpecy way to do this, despite being longer. In both cases they dig into people (either checking the size or checking that it calls <<), but in the latter case it verifies behavior, rather than inferring it from state. Does that sound right? Pat From dchelimsky at gmail.com Mon Nov 27 07:09:32 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 27 Nov 2006 07:09:32 -0500 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <810a540e0611270053s5a8aa82y8225f0150caccacb@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> <810a540e0611270053s5a8aa82y8225f0150caccacb@mail.gmail.com> Message-ID: <57c63afe0611270409g6c1cc615l7d01df3496ce1@mail.gmail.com> On 11/27/06, Pat Maddox wrote: > Hey David, > > Thanks for the info. I know that it wasn't a bug in RSpec at all...I > was just describing something that I wanted to do, but couldn't at the > time. I posted it to say, "Hey this is my problem, I'm working on a > solution," and perhaps spark discussion if warranted. That's really what the mailing lists are for. If you really think it is an RSpec deficiency, by all means stick it in a Bug report or Feature Request, but in this case the mailing list is the right place to start. Perhaps the discussion ends up leading to RFEs and that's fine. > As I mentioned > in the report, I knew that the problem was I was using an array, and > actually I began writing a class that would act like the Rails > collection class for me. Then my girlfriend interrupted me... > > Glad she did :) Had another aha moment reading your post. > > On 11/26/06, David Chelimsky wrote: > > One goal of splitting specs into model, view, controller specs is to > > decouple the underlying AR behaviour from what you specify in a > > controller or view spec. > > > > What I would do in the example that Pat provided is specify > > validations in the model specs and then mock out the models in the > > controller specs. Given your current implementation, you could have > > the following spec: > > > > specify "should create a new Person and stick it in the users people" do > > mock_user = mock("user") > > mock_person = mock("person") > > mock_people = mock("user people") > > mock_user.should_receive(:people).and_return(mock_people) > > mock_people.should_receive(:<<).with(mock_person) > > > > User.should_receive(:find_by_login).with("pat").and_return(mock_user) > > Person.should_receive(:new).with(:name => "BJ").and_return(mock_person) > > > > post :create, :user_id => "pat", :person => { :name => "BJ" } > > end > > > > If that seems like a lot of mocking to you (it does to me), that's > > because adding something to @user.people in this context is a > > violation of Tell, Don't Ask and also smells like Feature Envy (when > > one object operates on the data of another). > > I see what you mean. At first I thought it wasn't a big deal, because > we're just telling the people collection to add another person. But > really, we're asking for the people collection, and then telling it to > do something, when we're really interacting with the user object. > There's no need to know that there's a collection of people. > > Interestingly, if I were to see > people = user.people > people << person > > I'd instantly identify that as a code smell. Perhaps it all being on > the same line and the syntactic sugar of << hid it from me. Totally. That's something we'll all fall sucker to at one point or another. > > > This could be solved by > > adding an add_person method to User. Now your controller spec could > > look like this: > > > > specify "should create a new Person and stick it in the users people" do > > mock_user = mock("user") > > mock_person = mock("person") > > mock_user.should_receive(:add_person).with(mock_person) > > > > User.should_receive(:find_by_login).with("pat").and_return(mock_user) > > Person.should_receive(:new).with(:name => "BJ").and_return(mock_person) > > > > post :create, :user_id => "pat", :person => { :name => "BJ" } > > end > > > > and the create method: > > > > def create > > @user = User.find_by_login params[:user_id] > > @person = Person.new params[:person] > > @user.add_person @person > > redirect_to person_path(@user, @person) > > end > > > > Small change to the create method. Not so small implications in terms > > of decoupling the design. > > > > No intent to dis your design here, Pat. I've certainly done much worse > > that that along the way! The problem is that ActiveRecord encourages > > this sort of highly coupled design, and the problems that go along > > with it (like having to do many layers of mocking in your specs). It's > > one of those situations in which we get so much good from AR that we > > have to live w/ the design problems it encourages, and try to address > > them through discussion and education. And that's why I believe so > > strongly in the approach we're trying to take w/ the rails plugin. > > No problem at all, I'm glad you brought this up. In other languages > or frameworks I would create an add_person method...but for some > reason this case didn't jump out at me as breaking encapsulation. Of > course it'll be easier to recognize and avoid the problem in the > future though. > > So I think I've learned a lesson here...if it's hard for me to do > something, it's likely a deficiency in my design. I couldn't get the > expectations to work like I wanted, because I was using mocks wrong, > because my design was too tightly coupled. > > Thank you very much for taking the time to discuss this. I'm looking > forward to making more (different!) mistakes :) No worries. As I said above, that's what these lists are for. Perhaps this particular thread might even be better on the rspec-users list. That's the problem w/ multiple lists. Maybe you'd consider blogging some of this as it becomes more clear to you. Cheers, David > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Nov 27 07:35:32 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 27 Nov 2006 07:35:32 -0500 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> Message-ID: <57c63afe0611270435x3c750b25scddfb4c9e3621c0c@mail.gmail.com> On 11/27/06, Pat Maddox wrote: > On 11/26/06, David Chelimsky wrote: > > This could be solved by > > adding an add_person method to User. Now your controller spec could > > look like this: > > > > specify "should create a new Person and stick it in the users people" do > > mock_user = mock("user") > > mock_person = mock("person") > > mock_user.should_receive(:add_person).with(mock_person) > > > > User.should_receive(:find_by_login).with("pat").and_return(mock_user) > > Person.should_receive(:new).with(:name => "BJ").and_return(mock_person) > > > > post :create, :user_id => "pat", :person => { :name => "BJ" } > > end > > If I want to specify the redirect, would I do > > specify "should redirect to the new person" do > mock_user = mock("user", :null_object => true) > mock_person = mock("person") > > mock_user.should_receive(:to_param).and_return("pat") > mock_person.should_receive(:to_param).and_return(1) > > User.should_receive(:find_by_login).with("pat").and_return(mock_user) > Person.should_receive(:new).with("name" => "BJ").and_return(mock_person) > > controller.should_redirect_to :action => "show", :user_id => "pat", > :id => 1 > post :create, :user_id => "pat", :person => { :name => "BJ" } > end > > or should I just include the controller.should_redirect_to in the > first spec I showed? I try to stick to Dave Astels' "One Expectation > Per Example" guideline...and I usually do fine when writing model > code, or standalone classes, but obviously neither of these examples > follows that at all closely. Is it even possible to follow it with > controller specs? I'm trying to get some heuristics for determining > how much is too much in a single spec. > > In my example, redirecting behavior doesn't have anything to do with > the behavior of adding a user, so I think they should be split out. > But then there's a lot of code in the second spec that has nothing to > do with the redirect behavior (User.find and Person.new certainly > don't have anything to do with that). Is that just a consequence of > all that goes on in an action, or is it a sign that there's room to > refactor? Here's how I've been handling this sort of thing. Bear in mind that I am a big fan of either "One Expectation Per Example", for which I make exceptions when the expectations are very cohesive. In this case, I think they are sufficiently un-cohesive to warrant their own specs. context "Given a post to :create, the UserController should" do # Use stubs in setup just to get things to run - this is just # noise, but necessary noise, and less noisy when in setup that # in individual specs. setup do @mock_user = mock("user") @mock_person = mock("person") @mock_user.stub!(:to_param).and_return("pat") @mock_user.stub!(:add_person) @mock_person.stub!(:to_param).and_return(1) User.stub!(:find_by_login).and_return(@mock_user) Person.stub!(:new).and_return(@mock_person) end def do_post post :create, :user_id => "pat", :person => { :name => "BJ" } end # Use mock expectations (should_receive) in the specify blocks. Even # though they are redundant with the stubs in setup, they help tell # the story of this particular spec. specify "find the relevant User" do User.should_receive(:find_by_login).with("pat").and_return(@mock_user) do_post end specify "create a new Person" do Person.should_receive(:new).with(:name => "BJ").and_return(@mock_person) do_post end specify "add the new Person to the User" do @mock_user.should_receive(:add_person).with(@mock_person) do_post end #example using controller expectations specify "redirect to the new Person" do controller.should_redirect_to :action => "show", :user_id => "pat", :id => 1 do_post end #example using response expectations specify "redirect to the new Person" do do_post response.redirect_url.should_eql "http://test.host/users/show/1" end end This approach allows you to separate concerns in different specs while minimizing noise within each spec. Looking at setup tells you everything that has to happen just to get things to run, and can often reveal code smells that you might not otherwise see. Also, the output is quite nice: Given a post to :create, the UserController should - find the relevant User - create a new Person - add the new Person to the User - redirect to the new Person Looking at that is helpful too. Perhaps this would be fine: Given a post to :create, the UserController should - find the relevant User - create a new Person and add it to the User - redirect to the new Person or even this: Given a post to :create, the UserController should - find the relevant User, create a new Person and add it to the User - redirect to the new Person Looking at it this way, the specs that I've combined do seem cohesive so I'd be comfortable with this or with each one separated out. Hope this is all helpful. Cheers, David > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Nov 27 07:45:16 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 27 Nov 2006 07:45:16 -0500 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <810a540e0611270154x162d61byb16ed1401997e455@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> <810a540e0611270154x162d61byb16ed1401997e455@mail.gmail.com> Message-ID: <57c63afe0611270445q29de67darde52bf7b65c0cfdb@mail.gmail.com> On 11/27/06, Pat Maddox wrote: > Another question :) > > When I first wrote the add_person method, my spec looked like this: > > specify "should accept a new person" do > @user.people.size.should_be 0 > @user.add_person Person.new > @user.people.size.should_be 1 > end > > That works, of course, and lets me infer that I have the new user. > However I think it's ugly that I'm accessing people to verify > something about the user... > > So then I decided to change it to this: > > specify "should accept a new person" do > mock_person = mock("person") > mock_people = mock("people") > @user.should_receive(:people).and_return(mock_people) > mock_people.should_receive(:<<).with(mock_person) > @user.add_person mock_person > end > > That feels like the more RSpecy way to do this, despite being longer. > In both cases they dig into people (either checking the size or > checking that it calls <<), but in the latter case it verifies > behavior, rather than inferring it from state. Does that sound right? This one is tricky. There are multiple perspectives on how much mocking you should do in model specs. One view is that model specs are really small integration specs (model class + database). Another view is that you should do what you did above, mocking out the other players where possible. I'm leaning towards the first view - that model specs are like little integration specs. My thinking is that because the way AR is designed, the things you end up mocking are often internal to AR, which is a huge mocking no-no (mock YOUR code, not other people's). In this case you could use this to make it feel more RSpecy without mocking anything: specify "should accept a new person" do lambda do @user.add_person end.should_change(@user.people.size).by(1) end I'm not a huge fan of going after @user.people.size here, but I think that @user.number_of_people might be overkill. This is all pretty tricky territory for me. Not nearly as clear as how to handle the controllers (to me). And, in my view, it boils down to AR's use of inheritance rather than composition. Cheers, David > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From pergesu at gmail.com Mon Nov 27 15:56:41 2006 From: pergesu at gmail.com (Pat Maddox) Date: Mon, 27 Nov 2006 13:56:41 -0700 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <57c63afe0611270445q29de67darde52bf7b65c0cfdb@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> <810a540e0611270154x162d61byb16ed1401997e455@mail.gmail.com> <57c63afe0611270445q29de67darde52bf7b65c0cfdb@mail.gmail.com> Message-ID: <810a540e0611271256g27986d52vb49cc2e78c78f057@mail.gmail.com> On 11/27/06, David Chelimsky wrote: > On 11/27/06, Pat Maddox wrote: > > Another question :) > > > > When I first wrote the add_person method, my spec looked like this: > > > > specify "should accept a new person" do > > @user.people.size.should_be 0 > > @user.add_person Person.new > > @user.people.size.should_be 1 > > end > > > > That works, of course, and lets me infer that I have the new user. > > However I think it's ugly that I'm accessing people to verify > > something about the user... > > > > So then I decided to change it to this: > > > > specify "should accept a new person" do > > mock_person = mock("person") > > mock_people = mock("people") > > @user.should_receive(:people).and_return(mock_people) > > mock_people.should_receive(:<<).with(mock_person) > > @user.add_person mock_person > > end > > > > That feels like the more RSpecy way to do this, despite being longer. > > In both cases they dig into people (either checking the size or > > checking that it calls <<), but in the latter case it verifies > > behavior, rather than inferring it from state. Does that sound right? > > This one is tricky. There are multiple perspectives on how much > mocking you should do in model specs. One view is that model specs are > really small integration specs (model class + database). Another view > is that you should do what you did above, mocking out the other > players where possible. > > I'm leaning towards the first view - that model specs are like little > integration specs. My thinking is that because the way AR is designed, > the things you end up mocking are often internal to AR, which is a > huge mocking no-no (mock YOUR code, not other people's). Weren't we mocking other people's code in the controller specs as well? ARClass.should_receive(:find).with(1).and_return(some_mock_object) ARClass.should_receive(:new).with(:name => "name").and_return(other_mock_object) I'm not really sure what the difference is between mocking that out and mocking players. At first I thought that it's because the find and new calls appear in my code, but so does players <<. > In this case you could use this to make it feel more RSpecy without > mocking anything: > > specify "should accept a new person" do > lambda do > @user.add_person > end.should_change(@user.people.size).by(1) > end > > I'm not a huge fan of going after @user.people.size here, but I think > that @user.number_of_people might be overkill. After thinking about this some more, I think I like the other version with lots of mocks. To me, it boils down to what I think is a revelation I had last night...using the specs do define behavior, rather than infer it from state. The one problem I see with my example was what if the User object doesn't define a players method? Then the spec passes fine, but the code blows up of course. This would be easily solved if you ensure that partial mocks can only mock methods that the object already has. for example, I've got a user object that has players in this case...when I do user.should_receive(:players) then I think the should_receive call out to call user.respond_to?(players) before mocking the method. That seems reasonable to me for partial mocks - we're just substituting in some code for behavior that should already exist, because the existing code is too complex or expensive and doesn't need to be executed at the moment. At the very least, perhaps it could generate a warning such as "WARNING - 'people' not defined on user object." WDYT? Pat From aslak.hellesoy at gmail.com Mon Nov 27 16:05:03 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 27 Nov 2006 22:05:03 +0100 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <810a540e0611271256g27986d52vb49cc2e78c78f057@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> <810a540e0611270154x162d61byb16ed1401997e455@mail.gmail.com> <57c63afe0611270445q29de67darde52bf7b65c0cfdb@mail.gmail.com> <810a540e0611271256g27986d52vb49cc2e78c78f057@mail.gmail.com> Message-ID: <8d961d900611271305v59b06299lf2b9acdc5bf4aecf@mail.gmail.com> On 11/27/06, Pat Maddox wrote: > On 11/27/06, David Chelimsky wrote: > > On 11/27/06, Pat Maddox wrote: > > > Another question :) > > > > > > When I first wrote the add_person method, my spec looked like this: > > > > > > specify "should accept a new person" do > > > @user.people.size.should_be 0 > > > @user.add_person Person.new > > > @user.people.size.should_be 1 > > > end > > > > > > That works, of course, and lets me infer that I have the new user. > > > However I think it's ugly that I'm accessing people to verify > > > something about the user... > > > > > > So then I decided to change it to this: > > > > > > specify "should accept a new person" do > > > mock_person = mock("person") > > > mock_people = mock("people") > > > @user.should_receive(:people).and_return(mock_people) > > > mock_people.should_receive(:<<).with(mock_person) > > > @user.add_person mock_person > > > end > > > > > > That feels like the more RSpecy way to do this, despite being longer. > > > In both cases they dig into people (either checking the size or > > > checking that it calls <<), but in the latter case it verifies > > > behavior, rather than inferring it from state. Does that sound right? > > > > This one is tricky. There are multiple perspectives on how much > > mocking you should do in model specs. One view is that model specs are > > really small integration specs (model class + database). Another view > > is that you should do what you did above, mocking out the other > > players where possible. > > > > I'm leaning towards the first view - that model specs are like little > > integration specs. My thinking is that because the way AR is designed, > > the things you end up mocking are often internal to AR, which is a > > huge mocking no-no (mock YOUR code, not other people's). > > Weren't we mocking other people's code in the controller specs as well? > ARClass.should_receive(:find).with(1).and_return(some_mock_object) > ARClass.should_receive(:new).with(:name => "name").and_return(other_mock_object) > > I'm not really sure what the difference is between mocking that out > and mocking players. At first I thought that it's because the find > and new calls appear in my code, but so does players <<. > > > > In this case you could use this to make it feel more RSpecy without > > mocking anything: > > > > specify "should accept a new person" do > > lambda do > > @user.add_person > > end.should_change(@user.people.size).by(1) > > end > > > > I'm not a huge fan of going after @user.people.size here, but I think > > that @user.number_of_people might be overkill. > > After thinking about this some more, I think I like the other version > with lots of mocks. To me, it boils down to what I think is a > revelation I had last night...using the specs do define behavior, > rather than infer it from state. > > The one problem I see with my example was what if the User object > doesn't define a players method? Then the spec passes fine, but the > code blows up of course. This would be easily solved if you ensure > that partial mocks can only mock methods that the object already has. > > for example, I've got a user object that has players in this case...when I do > user.should_receive(:players) > then I think the should_receive call out to call > user.respond_to?(players) before mocking the method. That seems > reasonable to me for partial mocks - we're just substituting in some > code for behavior that should already exist, because the existing code > is too complex or expensive and doesn't need to be executed at the > moment. At the very least, perhaps it could generate a warning such > as "WARNING - 'people' not defined on user object." WDYT? > That would be possible to bake into RSpec, but it would violate one of the main principles of BDD. BDD is (among other things) a technique to *discover* the interfaces of neighbouring objects N while speccing a class C. And while you're speccing C, N might not even exist. The WARNING idea is interesting though. > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Nov 27 17:38:35 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 27 Nov 2006 17:38:35 -0500 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <8d961d900611271305v59b06299lf2b9acdc5bf4aecf@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> <810a540e0611270154x162d61byb16ed1401997e455@mail.gmail.com> <57c63afe0611270445q29de67darde52bf7b65c0cfdb@mail.gmail.com> <810a540e0611271256g27986d52vb49cc2e78c78f057@mail.gmail.com> <8d961d900611271305v59b06299lf2b9acdc5bf4aecf@mail.gmail.com> Message-ID: <57c63afe0611271438n44b5ef1dpf6108ed15c5f76cd@mail.gmail.com> On 11/27/06, aslak hellesoy wrote: > On 11/27/06, Pat Maddox wrote: > > On 11/27/06, David Chelimsky wrote: > > > On 11/27/06, Pat Maddox wrote: > > > > Another question :) > > > > > > > > When I first wrote the add_person method, my spec looked like this: > > > > > > > > specify "should accept a new person" do > > > > @user.people.size.should_be 0 > > > > @user.add_person Person.new > > > > @user.people.size.should_be 1 > > > > end > > > > > > > > That works, of course, and lets me infer that I have the new user. > > > > However I think it's ugly that I'm accessing people to verify > > > > something about the user... > > > > > > > > So then I decided to change it to this: > > > > > > > > specify "should accept a new person" do > > > > mock_person = mock("person") > > > > mock_people = mock("people") > > > > @user.should_receive(:people).and_return(mock_people) > > > > mock_people.should_receive(:<<).with(mock_person) > > > > @user.add_person mock_person > > > > end > > > > > > > > That feels like the more RSpecy way to do this, despite being longer. > > > > In both cases they dig into people (either checking the size or > > > > checking that it calls <<), but in the latter case it verifies > > > > behavior, rather than inferring it from state. Does that sound right? > > > > > > This one is tricky. There are multiple perspectives on how much > > > mocking you should do in model specs. One view is that model specs are > > > really small integration specs (model class + database). Another view > > > is that you should do what you did above, mocking out the other > > > players where possible. > > > > > > I'm leaning towards the first view - that model specs are like little > > > integration specs. My thinking is that because the way AR is designed, > > > the things you end up mocking are often internal to AR, which is a > > > huge mocking no-no (mock YOUR code, not other people's). > > > > Weren't we mocking other people's code in the controller specs as well? > > ARClass.should_receive(:find).with(1).and_return(some_mock_object) > > ARClass.should_receive(:new).with(:name => "name").and_return(other_mock_object) > > > > I'm not really sure what the difference is between mocking that out > > and mocking players. At first I thought that it's because the find > > and new calls appear in my code, but so does players <<. > > > > > > > In this case you could use this to make it feel more RSpecy without > > > mocking anything: > > > > > > specify "should accept a new person" do > > > lambda do > > > @user.add_person > > > end.should_change(@user.people.size).by(1) > > > end > > > > > > I'm not a huge fan of going after @user.people.size here, but I think > > > that @user.number_of_people might be overkill. > > > > After thinking about this some more, I think I like the other version > > with lots of mocks. To me, it boils down to what I think is a > > revelation I had last night...using the specs do define behavior, > > rather than infer it from state. > > > > The one problem I see with my example was what if the User object > > doesn't define a players method? Then the spec passes fine, but the > > code blows up of course. This would be easily solved if you ensure > > that partial mocks can only mock methods that the object already has. > > > > for example, I've got a user object that has players in this case...when I do > > user.should_receive(:players) > > then I think the should_receive call out to call > > user.respond_to?(players) before mocking the method. That seems > > reasonable to me for partial mocks - we're just substituting in some > > code for behavior that should already exist, because the existing code > > is too complex or expensive and doesn't need to be executed at the > > moment. At the very least, perhaps it could generate a warning such > > as "WARNING - 'people' not defined on user object." WDYT? > > > > That would be possible to bake into RSpec, but it would violate one of > the main principles of BDD. BDD is (among other things) a technique to > *discover* the interfaces of neighbouring objects N while speccing a > class C. And while you're speccing C, N might not even exist. > > The WARNING idea is interesting though. > > > Pat > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Nov 27 17:54:04 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 27 Nov 2006 17:54:04 -0500 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <57c63afe0611271438n44b5ef1dpf6108ed15c5f76cd@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> <810a540e0611270154x162d61byb16ed1401997e455@mail.gmail.com> <57c63afe0611270445q29de67darde52bf7b65c0cfdb@mail.gmail.com> <810a540e0611271256g27986d52vb49cc2e78c78f057@mail.gmail.com> <8d961d900611271305v59b06299lf2b9acdc5bf4aecf@mail.gmail.com> <57c63afe0611271438n44b5ef1dpf6108ed15c5f76cd@mail.gmail.com> Message-ID: <57c63afe0611271454h259b26a3te0b6a5c8471af485@mail.gmail.com> As usual, I said nothing..... (accidentally hit send instead of discard). Anyhow - comments below.... On 11/27/06, David Chelimsky wrote: > On 11/27/06, aslak hellesoy wrote: > > On 11/27/06, Pat Maddox wrote: > > > On 11/27/06, David Chelimsky wrote: > > > > On 11/27/06, Pat Maddox wrote: > > > > > Another question :) > > > > > > > > > > When I first wrote the add_person method, my spec looked like this: > > > > > > > > > > specify "should accept a new person" do > > > > > @user.people.size.should_be 0 > > > > > @user.add_person Person.new > > > > > @user.people.size.should_be 1 > > > > > end > > > > > > > > > > That works, of course, and lets me infer that I have the new user. > > > > > However I think it's ugly that I'm accessing people to verify > > > > > something about the user... > > > > > > > > > > So then I decided to change it to this: > > > > > > > > > > specify "should accept a new person" do > > > > > mock_person = mock("person") > > > > > mock_people = mock("people") > > > > > @user.should_receive(:people).and_return(mock_people) > > > > > mock_people.should_receive(:<<).with(mock_person) > > > > > @user.add_person mock_person > > > > > end > > > > > > > > > > That feels like the more RSpecy way to do this, despite being longer. > > > > > In both cases they dig into people (either checking the size or > > > > > checking that it calls <<), but in the latter case it verifies > > > > > behavior, rather than inferring it from state. Does that sound right? > > > > > > > > This one is tricky. There are multiple perspectives on how much > > > > mocking you should do in model specs. One view is that model specs are > > > > really small integration specs (model class + database). Another view > > > > is that you should do what you did above, mocking out the other > > > > players where possible. > > > > > > > > I'm leaning towards the first view - that model specs are like little > > > > integration specs. My thinking is that because the way AR is designed, > > > > the things you end up mocking are often internal to AR, which is a > > > > huge mocking no-no (mock YOUR code, not other people's). > > > > > > Weren't we mocking other people's code in the controller specs as well? > > > ARClass.should_receive(:find).with(1).and_return(some_mock_object) > > > ARClass.should_receive(:new).with(:name => "name").and_return(other_mock_object) I think one *could* argue that mocking :find is closer to mocking your own code (as it is a method that appears on *your* AR subclass, even though it is implemented above) than mocking the collection that AR makes available when you ask it for a collection property. As I said before, this is very gray area, thanks to being cornered into inheritance rather than composition. That sounds whiny, I know. What can I say? When something is SO close to being really great, you're more likely to notice its flaws than its lesser counterparts. > > > > > > I'm not really sure what the difference is between mocking that out > > > and mocking players. At first I thought that it's because the find > > > and new calls appear in my code, but so does players <<. > > > > > > > > > > In this case you could use this to make it feel more RSpecy without > > > > mocking anything: > > > > > > > > specify "should accept a new person" do > > > > lambda do > > > > @user.add_person > > > > end.should_change(@user.people.size).by(1) > > > > end > > > > > > > > I'm not a huge fan of going after @user.people.size here, but I think > > > > that @user.number_of_people might be overkill. > > > > > > After thinking about this some more, I think I like the other version > > > with lots of mocks. To me, it boils down to what I think is a > > > revelation I had last night...using the specs do define behavior, > > > rather than infer it from state. > > > > > > The one problem I see with my example was what if the User object > > > doesn't define a players method? Then the spec passes fine, but the > > > code blows up of course. This would be easily solved if you ensure > > > that partial mocks can only mock methods that the object already has. > > > > > > for example, I've got a user object that has players in this case...when I do > > > user.should_receive(:players) > > > then I think the should_receive call out to call > > > user.respond_to?(players) before mocking the method. That seems > > > reasonable to me for partial mocks - we're just substituting in some > > > code for behavior that should already exist, because the existing code > > > is too complex or expensive and doesn't need to be executed at the > > > moment. At the very least, perhaps it could generate a warning such > > > as "WARNING - 'people' not defined on user object." WDYT? > > > > > > > That would be possible to bake into RSpec, but it would violate one of > > the main principles of BDD. BDD is (among other things) a technique to > > *discover* the interfaces of neighbouring objects N while speccing a > > class C. And while you're speccing C, N might not even exist. > > > > The WARNING idea is interesting though. RFE [#5064] (Let mock() take a class argument) seems to be addressing the similar issue. If we do something like this, I'd like to see it be modal. Under normal spec runs it has no effect, but w/ a command line switch you can get a report of what's being mocked that doesn't exist yet. I also added a comment describing a vague vision (I don't really know how this would work) in which if you use a class argument you could get the specs to run in an integration mode in which real instances of the class get substituted for the mocks, thereby allowing the specs to serve as both isolation and integration specs. This is not an original idea - Dan introduced something similar in JBehave, and someone on one of these lists wrote about it as well some time ago. But it's worth investigating, I think. > > > > > Pat > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From noreply at rubyforge.org Mon Nov 27 18:01:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Nov 2006 18:01:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6898 ] Can we separate rspec from the plugins? Message-ID: <20061127230113.E974F5241911@rubyforge.org> Feature Requests item #6898, was opened at 2006-11-26 23:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Can we separate rspec from the plugins? Initial Comment: I'm trying to use rspec to do my rails development, and a while ago I had found a way to be able to use edge rspec and the plugin. Today I svn uped and to my surprise, the rspec code (not the plugin) ended up downloading three different versions of Rails. Is there any way we can separate the rspec code base from the plugins? If I download trunk, I just want it to be rspec itself...the Rails stuff shouldn't be under it. If I'm in a Rails project, I can install the rspec libs as a plugin, and the Rails plugin separately. Some of you may have seen my article a couple weeks ago about doing that (site is no longer up, sorry). Basically now it's a real pain to try to use edge rspec inside a Rails project. However that's the best way to make updates both to rspec itself and the plugin. If you could make it so they're separated more cleanly, I'd happily bang out Rails related bugs and RFEs as I work on my own Rails apps. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-27 23:01 Message: That sounds like a great idea. The only annoyance would be when people who have rspec installed a gem run 'spec' instead of 'script/spec'. If the versions differ, they'll get a warning. Perhaps that warning, which is specific to the rails plugin, should recommend using 'script/spec'??? re: freezing to do this in trunk - I think that's how we should go. Let's just agree on a time a couple of days in advance so that anybody who is working on stuff has plenty of warning. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-27 01:58 Message: The only thing here is the spec script. If a Rails app includes RSpec as a plugin, then the spec command will be deep down in vendor/plugins/rspec/bin/spec That's a bit clunky to run from the commandline. Perhaps script/generate rspec should create a script/spec command if vendor/plugins/rspec/bin/spec is present? script/spec would just load vendor/plugins/rspec/bin/spec WDYT? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-27 01:34 Message: iirc, it won't. When you do the mv it simply does an add and delete, and as far as svn is concerned there is no link between the files. So basically if you're planning on doing this, it'd be best for everyone else to freeze until you get it done. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-27 01:18 Message: Ok, I can drive it. I'll probably do it on a branch. Does anyone know if svn handles a merge back to trunk when files have been moved on the branch and modified on the trunk in the meanwhile? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-27 01:03 Message: One thing about separating rspec_on_rails and rspec_on_rails_demo. Right now, the specs inside rspec_on_rails won't work w/o the demo in place (because the demo also houses files specifically present for the specs). So, initially, we'd run the specs via the demo, but eventually we want to make the rspec_on_rails tree be complete (i.e. you can run all the specs within that tree). Make sense? Otherwise, this sounds good. I think we should plan a time to do this. Aslak - do you want to drive it? Thanks, David ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-27 00:56 Message: On top of svn mv and rake hacking, you'll have to edit all the files that "require 'some_other_file'" to use relative paths. When I was splitting stuff out on my own that's what I had to do...but it's not too bad. The proposed structure is basically exactly what I'd like to see. Makes it really easy to include just what you want, which of course makes it easy to make changes. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-27 00:40 Message: Reorganising things is the kind of thing that is hard to submit a patch for. It's just a bunch of svn mv (plus a little rake hacking). Let's discuss the proposed layout here. This is my initial suggestion (everything is under trunk) Rakefile # Delegates to sub Rakefiles - for running *all* specs rspec/init.rb # The core - requires the three subprojects, each of which have their own lib and spec dir rspec/expectations rspec/context_runner rspec/mocks jruby/ RSpec.tmbundle/ rspec_on_rails/ rspec_on_rails_demo/ # Could pull in rspec_on_rails via svn:external selenium/ watir/ This organisation would allow Rails projects to install RSpec as 2 Rails plugins: rspec and rspec_on_rails WDYT? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-27 00:18 Message: "And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well." That's what I meant by bang out bugs and RFEs :) I'll go through the list and write patches, as well as come up with whatever other patches I need as I write my Rails app. Just kinda tough with the current structure...any timeline on when things will be cleaner? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-27 00:13 Message: Absolutely! We've been wanting to restructure things and this is one of the issues under discussion. We'll address this soon. When we're ready to, there will be an email to the list in advance so that those who do prefer to work from source won't be all screwed up by it. And, of course, bugs and RFEs are most welcome. Feel free to contribute patches as well. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6898&group_id=797 From pergesu at gmail.com Mon Nov 27 18:34:19 2006 From: pergesu at gmail.com (Pat Maddox) Date: Mon, 27 Nov 2006 16:34:19 -0700 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <57c63afe0611271454h259b26a3te0b6a5c8471af485@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> <810a540e0611270154x162d61byb16ed1401997e455@mail.gmail.com> <57c63afe0611270445q29de67darde52bf7b65c0cfdb@mail.gmail.com> <810a540e0611271256g27986d52vb49cc2e78c78f057@mail.gmail.com> <8d961d900611271305v59b06299lf2b9acdc5bf4aecf@mail.gmail.com> <57c63afe0611271438n44b5ef1dpf6108ed15c5f76cd@mail.gmail.com> <57c63afe0611271454h259b26a3te0b6a5c8471af485@mail.gmail.com> Message-ID: <810a540e0611271534l148004c2t205038ce33e5c01d@mail.gmail.com> On 11/27/06, David Chelimsky wrote: > As usual, I said nothing..... (accidentally hit send instead of > discard). Anyhow - comments below.... > > On 11/27/06, David Chelimsky wrote: > > On 11/27/06, aslak hellesoy wrote: > > > On 11/27/06, Pat Maddox wrote: > > > > On 11/27/06, David Chelimsky wrote: > > > > > On 11/27/06, Pat Maddox wrote: > > > > > > Another question :) > > > > > > > > > > > > When I first wrote the add_person method, my spec looked like this: > > > > > > > > > > > > specify "should accept a new person" do > > > > > > @user.people.size.should_be 0 > > > > > > @user.add_person Person.new > > > > > > @user.people.size.should_be 1 > > > > > > end > > > > > > > > > > > > That works, of course, and lets me infer that I have the new user. > > > > > > However I think it's ugly that I'm accessing people to verify > > > > > > something about the user... > > > > > > > > > > > > So then I decided to change it to this: > > > > > > > > > > > > specify "should accept a new person" do > > > > > > mock_person = mock("person") > > > > > > mock_people = mock("people") > > > > > > @user.should_receive(:people).and_return(mock_people) > > > > > > mock_people.should_receive(:<<).with(mock_person) > > > > > > @user.add_person mock_person > > > > > > end > > > > > > > > > > > > That feels like the more RSpecy way to do this, despite being longer. > > > > > > In both cases they dig into people (either checking the size or > > > > > > checking that it calls <<), but in the latter case it verifies > > > > > > behavior, rather than inferring it from state. Does that sound right? > > > > > > > > > > This one is tricky. There are multiple perspectives on how much > > > > > mocking you should do in model specs. One view is that model specs are > > > > > really small integration specs (model class + database). Another view > > > > > is that you should do what you did above, mocking out the other > > > > > players where possible. > > > > > > > > > > I'm leaning towards the first view - that model specs are like little > > > > > integration specs. My thinking is that because the way AR is designed, > > > > > the things you end up mocking are often internal to AR, which is a > > > > > huge mocking no-no (mock YOUR code, not other people's). > > > > > > > > Weren't we mocking other people's code in the controller specs as well? > > > > ARClass.should_receive(:find).with(1).and_return(some_mock_object) > > > > ARClass.should_receive(:new).with(:name => "name").and_return(other_mock_object) > > I think one *could* argue that mocking :find is closer to mocking your > own code (as it is a method that appears on *your* AR subclass, even > though it is implemented above) than mocking the collection that AR > makes available when you ask it for a collection property. As I said > before, this is very gray area, thanks to being cornered into > inheritance rather than composition. That sounds whiny, I know. What > can I say? When something is SO close to being really great, you're > more likely to notice its flaws than its lesser counterparts. I guess that's where I'm confused...the collection is defined on *your* AR subclass as well. Would you mind clarifying the difference you see between MyClass.find and my_instance.items? The latter case is even more custom because it's not automatically implemented higher in the heirarchy, but rather is defined only after you call "has_many :items" > > > > I'm not really sure what the difference is between mocking that out > > > > and mocking players. At first I thought that it's because the find > > > > and new calls appear in my code, but so does players <<. > > > > > > > > > > > > > In this case you could use this to make it feel more RSpecy without > > > > > mocking anything: > > > > > > > > > > specify "should accept a new person" do > > > > > lambda do > > > > > @user.add_person > > > > > end.should_change(@user.people.size).by(1) > > > > > end > > > > > > > > > > I'm not a huge fan of going after @user.people.size here, but I think > > > > > that @user.number_of_people might be overkill. > > > > > > > > After thinking about this some more, I think I like the other version > > > > with lots of mocks. To me, it boils down to what I think is a > > > > revelation I had last night...using the specs do define behavior, > > > > rather than infer it from state. > > > > > > > > The one problem I see with my example was what if the User object > > > > doesn't define a players method? Then the spec passes fine, but the > > > > code blows up of course. This would be easily solved if you ensure > > > > that partial mocks can only mock methods that the object already has. > > > > > > > > for example, I've got a user object that has players in this case...when I do > > > > user.should_receive(:players) > > > > then I think the should_receive call out to call > > > > user.respond_to?(players) before mocking the method. That seems > > > > reasonable to me for partial mocks - we're just substituting in some > > > > code for behavior that should already exist, because the existing code > > > > is too complex or expensive and doesn't need to be executed at the > > > > moment. At the very least, perhaps it could generate a warning such > > > > as "WARNING - 'people' not defined on user object." WDYT? > > > > > > > > > > That would be possible to bake into RSpec, but it would violate one of > > > the main principles of BDD. BDD is (among other things) a technique to > > > *discover* the interfaces of neighbouring objects N while speccing a > > > class C. And while you're speccing C, N might not even exist. > > > > > > The WARNING idea is interesting though. > > RFE [#5064] (Let mock() take a class argument) seems to be addressing > the similar issue. > > If we do something like this, I'd like to see it be modal. Under > normal spec runs it has no effect, but w/ a command line switch you > can get a report of what's being mocked that doesn't exist yet. I also > added a comment describing a vague vision (I don't really know how > this would work) in which if you use a class argument you could get > the specs to run in an integration mode in which real instances of the > class get substituted for the mocks, thereby allowing the specs to > serve as both isolation and integration specs. This is not an original > idea - Dan introduced something similar in JBehave, and someone on one > of these lists wrote about it as well some time ago. But it's worth > investigating, I think. I agree that it would be better to use a command line switch to report warnings. One problem I initially saw is when some methods are handled by method_missing, such as find_by_login. We wouldn't want warnings polluting the spec output when the method call is in fact valid, albeit not defined on the object itself. I remember reading about the integration mode, and I think it would be very good. You can use the current way to drive your design well, and then use integration mode to ensure that the entire stack works properly. This would serve a different purpose from the Rails integration tests, which imo are to prove workflow through your application. Pat From noreply at rubyforge.org Mon Nov 27 18:46:03 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Nov 2006 18:46:03 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6925 ] support controller.should_render :action_name Message-ID: <20061127234603.1FD8E52418AA@rubyforge.org> Feature Requests item #6925, was opened at 2006-11-27 23:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6925&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: support controller.should_render :action_name Initial Comment: specify "should render edit" do controller.should_render :edit end That is not currently supported. You get an error like: {:template=>\some_controller/edit\} should == {:edit} ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6925&group_id=797 From noreply at rubyforge.org Mon Nov 27 19:12:00 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Nov 2006 19:12:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6925 ] support controller.should_render :action_name Message-ID: <20061128001200.7809A52415C7@rubyforge.org> Feature Requests item #6925, was opened at 2006-11-27 23:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6925&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: support controller.should_render :action_name Initial Comment: specify "should render edit" do controller.should_render :edit end That is not currently supported. You get an error like: {:template=>\some_controller/edit\} should == {:edit} ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-28 00:11 Message: Added to trunk (rev 1159) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6925&group_id=797 From noreply at rubyforge.org Mon Nov 27 19:12:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Nov 2006 19:12:26 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6925 ] support controller.should_render :action_name Message-ID: <20061128001226.4E0625241A3F@rubyforge.org> Feature Requests item #6925, was opened at 2006-11-27 23:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6925&group_id=797 Category: rails plugin Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: support controller.should_render :action_name Initial Comment: specify "should render edit" do controller.should_render :edit end That is not currently supported. You get an error like: {:template=>\some_controller/edit\} should == {:edit} ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-28 00:11 Message: Added to trunk (rev 1159) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6925&group_id=797 From noreply at rubyforge.org Mon Nov 27 21:44:28 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Nov 2006 21:44:28 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6896 ] should_render fails with respond_to Message-ID: <20061128024428.1544B5241A7B@rubyforge.org> Bugs item #6896, was opened at 2006-11-26 23:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: David Chelimsky (dchelimsky) Summary: should_render fails with respond_to Initial Comment: Spec: specify "should show the form" do controller.should_render :template => "people/new" end Controller code: def new @person = Person.new respond_to do |format| format.html end end Failure: {:template=>"people/new"} should == {:action=>"new", :content_type=>#} ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-28 02:44 Message: I committed a first step towards this in trunk (rev 1160). It now supports format.html only. So far.... ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-27 00:20 Message: Edge rails, 0.7.3 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-27 00:20 Message: versions???? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6896&group_id=797 From noreply at rubyforge.org Mon Nov 27 21:48:47 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Nov 2006 21:48:47 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator Message-ID: <20061128024847.5367B5241A78@rubyforge.org> Feature Requests item #6098, was opened at 2006-10-11 10:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Make scaffold_resource generator Initial Comment: In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-28 02:48 Message: This is in the trunk now (as of rev 1160) but I'm not closing this because it's not yet tested in an automated way. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-26 20:18 Message: Luckliy I happened to have a copy of the code locally before the svn disappeared. I have attached it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-25 01:30 Message: Hey Pat - I went to http://svn.flpr.org/public/plugins/rspec_resource_generator to grab the latest source and couldn't get to it (can't even ping flpr.org). Would you mind posting a new link to it, or just attaching a patch to this ticket? I'd like to get this in soon. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 16:54 Message: I think the routing patch should be applied separately in spec/rails. We have to make it work with both 1.1.6 and Edge Rails. This brings up another issue - our build system needs to be able to run all spec/rails specs several times, typically once for the latest Rails release and once for edge. -Possibly with a mechanism to differentiate what's being run depending on the Rails version. I think the most pragmatic way to verify that this (and other generators) is working is to have the rake script (bootstrap_rspec.rake) execute the various generators before specs are run. And then delete the generated files afterwards (or maybe right before they're generated). This would require that we change the templates - right now they fail on purpose with "not enough specs". We should be able to generate stuff and have all specs pass. If you could help with any of this it would be fabulous! ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-09 16:35 Message: I applied the patch. Sorry about the routing method error...I completely forgot I had that in there. I saw your comment in http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6471&group_id=797 that it doesn't work in 1.1.6. What would you like me to do for this plugin? Should I move the routing method into the plugin itself? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 14:17 Message: I'm attaching a patch with some small improvements: should_eql and correct use of controller_class_name ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 13:41 Message: Looks like routing is defined in this "patch": http://rubyforge.org/tracker/index.php?func=detail&aid=6471&group_id=797&atid=3152 ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-09 13:34 Message: I tried this with RSpec's demo app (vendor/rspec_on_rails) - I created an account resource. The following code is failing: NoMethodError in 'The accountsController should map { :controller => 'accounts', :action => 'show', :id => 1 } to /accounts/1' undefined method `routing' for #<#:0x3b2d680> Where is this routing method defined? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-04 16:49 Message: My plugin at http://svn.flpr.org/public/plugins/rspec_resource_generator/ handles that. I removed the forked code, so the only template now is the controller_spec. Everything else is pulled from the standard Rails generators, and the rspec_model generator for the model spec. Anything else that should be done with that? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-04 09:28 Message: We should *not* fork/copy Rails code. Reuse all the existing templates, swap the test generation with spec generation (our own template). See the implementation of rspec_model and rspec_controller generators. ---------------------------------------------------------------------- Comment By: Jeff Dean (jefdean) Date: 2006-10-30 08:09 Message: I've written an rspec_scaffold_resource generator and I'm just waiting to here back on a few questions about directory changes in trunk before submitting the patch - Jeff Dean ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 From dchelimsky at gmail.com Mon Nov 27 23:55:35 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 27 Nov 2006 23:55:35 -0500 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <810a540e0611271534l148004c2t205038ce33e5c01d@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <57c63afe0611262240q580cabecveb1a66059c31de08@mail.gmail.com> <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> <810a540e0611270154x162d61byb16ed1401997e455@mail.gmail.com> <57c63afe0611270445q29de67darde52bf7b65c0cfdb@mail.gmail.com> <810a540e0611271256g27986d52vb49cc2e78c78f057@mail.gmail.com> <8d961d900611271305v59b06299lf2b9acdc5bf4aecf@mail.gmail.com> <57c63afe0611271438n44b5ef1dpf6108ed15c5f76cd@mail.gmail.com> <57c63afe0611271454h259b26a3te0b6a5c8471af485@mail.gmail.com> <810a540e0611271534l148004c2t205038ce33e5c01d@mail.gmail.com> Message-ID: <57c63afe0611272055y7e5e5ba0yeaf728eb68b8b691@mail.gmail.com> On 11/27/06, Pat Maddox wrote: > On 11/27/06, David Chelimsky wrote: > > As usual, I said nothing..... (accidentally hit send instead of > > discard). Anyhow - comments below.... > > > > On 11/27/06, David Chelimsky wrote: > > > On 11/27/06, aslak hellesoy wrote: > > > > On 11/27/06, Pat Maddox wrote: > > > > > On 11/27/06, David Chelimsky wrote: > > > > > > On 11/27/06, Pat Maddox wrote: > > > > > > > Another question :) > > > > > > > > > > > > > > When I first wrote the add_person method, my spec looked like this: > > > > > > > > > > > > > > specify "should accept a new person" do > > > > > > > @user.people.size.should_be 0 > > > > > > > @user.add_person Person.new > > > > > > > @user.people.size.should_be 1 > > > > > > > end > > > > > > > > > > > > > > That works, of course, and lets me infer that I have the new user. > > > > > > > However I think it's ugly that I'm accessing people to verify > > > > > > > something about the user... > > > > > > > > > > > > > > So then I decided to change it to this: > > > > > > > > > > > > > > specify "should accept a new person" do > > > > > > > mock_person = mock("person") > > > > > > > mock_people = mock("people") > > > > > > > @user.should_receive(:people).and_return(mock_people) > > > > > > > mock_people.should_receive(:<<).with(mock_person) > > > > > > > @user.add_person mock_person > > > > > > > end > > > > > > > > > > > > > > That feels like the more RSpecy way to do this, despite being longer. > > > > > > > In both cases they dig into people (either checking the size or > > > > > > > checking that it calls <<), but in the latter case it verifies > > > > > > > behavior, rather than inferring it from state. Does that sound right? > > > > > > > > > > > > This one is tricky. There are multiple perspectives on how much > > > > > > mocking you should do in model specs. One view is that model specs are > > > > > > really small integration specs (model class + database). Another view > > > > > > is that you should do what you did above, mocking out the other > > > > > > players where possible. > > > > > > > > > > > > I'm leaning towards the first view - that model specs are like little > > > > > > integration specs. My thinking is that because the way AR is designed, > > > > > > the things you end up mocking are often internal to AR, which is a > > > > > > huge mocking no-no (mock YOUR code, not other people's). > > > > > > > > > > Weren't we mocking other people's code in the controller specs as well? > > > > > ARClass.should_receive(:find).with(1).and_return(some_mock_object) > > > > > ARClass.should_receive(:new).with(:name => "name").and_return(other_mock_object) > > > > I think one *could* argue that mocking :find is closer to mocking your > > own code (as it is a method that appears on *your* AR subclass, even > > though it is implemented above) than mocking the collection that AR > > makes available when you ask it for a collection property. As I said > > before, this is very gray area, thanks to being cornered into > > inheritance rather than composition. That sounds whiny, I know. What > > can I say? When something is SO close to being really great, you're > > more likely to notice its flaws than its lesser counterparts. > > I guess that's where I'm confused...the collection is defined on > *your* AR subclass as well. Would you mind clarifying the difference > you see between MyClass.find and my_instance.items? The latter case > is even more custom because it's not automatically implemented higher > in the heirarchy, but rather is defined only after you call "has_many > :items" I'm confused too. > > > > > > > I'm not really sure what the difference is between mocking that out > > > > > and mocking players. At first I thought that it's because the find > > > > > and new calls appear in my code, but so does players <<. > > > > > > > > > > > > > > > > In this case you could use this to make it feel more RSpecy without > > > > > > mocking anything: > > > > > > > > > > > > specify "should accept a new person" do > > > > > > lambda do > > > > > > @user.add_person > > > > > > end.should_change(@user.people.size).by(1) > > > > > > end > > > > > > > > > > > > I'm not a huge fan of going after @user.people.size here, but I think > > > > > > that @user.number_of_people might be overkill. > > > > > > > > > > After thinking about this some more, I think I like the other version > > > > > with lots of mocks. To me, it boils down to what I think is a > > > > > revelation I had last night...using the specs do define behavior, > > > > > rather than infer it from state. > > > > > > > > > > The one problem I see with my example was what if the User object > > > > > doesn't define a players method? Then the spec passes fine, but the > > > > > code blows up of course. This would be easily solved if you ensure > > > > > that partial mocks can only mock methods that the object already has. > > > > > > > > > > for example, I've got a user object that has players in this case...when I do > > > > > user.should_receive(:players) > > > > > then I think the should_receive call out to call > > > > > user.respond_to?(players) before mocking the method. That seems > > > > > reasonable to me for partial mocks - we're just substituting in some > > > > > code for behavior that should already exist, because the existing code > > > > > is too complex or expensive and doesn't need to be executed at the > > > > > moment. At the very least, perhaps it could generate a warning such > > > > > as "WARNING - 'people' not defined on user object." WDYT? > > > > > > > > > > > > > That would be possible to bake into RSpec, but it would violate one of > > > > the main principles of BDD. BDD is (among other things) a technique to > > > > *discover* the interfaces of neighbouring objects N while speccing a > > > > class C. And while you're speccing C, N might not even exist. > > > > > > > > The WARNING idea is interesting though. > > > > RFE [#5064] (Let mock() take a class argument) seems to be addressing > > the similar issue. > > > > If we do something like this, I'd like to see it be modal. Under > > normal spec runs it has no effect, but w/ a command line switch you > > can get a report of what's being mocked that doesn't exist yet. I also > > added a comment describing a vague vision (I don't really know how > > this would work) in which if you use a class argument you could get > > the specs to run in an integration mode in which real instances of the > > class get substituted for the mocks, thereby allowing the specs to > > serve as both isolation and integration specs. This is not an original > > idea - Dan introduced something similar in JBehave, and someone on one > > of these lists wrote about it as well some time ago. But it's worth > > investigating, I think. > > I agree that it would be better to use a command line switch to report > warnings. One problem I initially saw is when some methods are > handled by method_missing, such as find_by_login. We wouldn't want > warnings polluting the spec output when the method call is in fact > valid, albeit not defined on the object itself. Should be ok if we use object.respond_to? > > I remember reading about the integration mode, and I think it would be > very good. You can use the current way to drive your design well, and > then use integration mode to ensure that the entire stack works > properly. This would serve a different purpose from the Rails > integration tests, which imo are to prove workflow through your > application. Right. Although, this will likely get VERY complicated because you'd have to have potentially two setups for every spec - one that uses mocks and one that uses the real objects. It's an interesting idea, but pretty low in priority. Doing something simpler, like running in a verification mode just to get a report on what methods aren't being implemented by the classes submitted as initialization args is more likely to happen sooner. So you'd do this: mock_thing = mock(Thing) When you do a normal spec run nothing happens. When you do spec --verify_mocked (or something like that) it would produce a simple report: Thing does not implement the following methods: - blah - ugh - doh - eek Or we could make it work more like the normal output: Thing should respond to the following messages: - blah - ugh (FAILED - NOT IMPLEMENTED) - doh - eek Any preference there? Cheers, David > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From pergesu at gmail.com Tue Nov 28 00:15:01 2006 From: pergesu at gmail.com (Pat Maddox) Date: Mon, 27 Nov 2006 22:15:01 -0700 Subject: [rspec-devel] Fwd: [ rspec-Bugs-6905 ] Mocking rails associations where the association is validated In-Reply-To: <57c63afe0611272055y7e5e5ba0yeaf728eb68b8b691@mail.gmail.com> References: <20061127063321.D84C05240C65@rubyforge.org> <810a540e0611270129h1caeef02w279a64e0266e6061@mail.gmail.com> <810a540e0611270154x162d61byb16ed1401997e455@mail.gmail.com> <57c63afe0611270445q29de67darde52bf7b65c0cfdb@mail.gmail.com> <810a540e0611271256g27986d52vb49cc2e78c78f057@mail.gmail.com> <8d961d900611271305v59b06299lf2b9acdc5bf4aecf@mail.gmail.com> <57c63afe0611271438n44b5ef1dpf6108ed15c5f76cd@mail.gmail.com> <57c63afe0611271454h259b26a3te0b6a5c8471af485@mail.gmail.com> <810a540e0611271534l148004c2t205038ce33e5c01d@mail.gmail.com> <57c63afe0611272055y7e5e5ba0yeaf728eb68b8b691@mail.gmail.com> Message-ID: <810a540e0611272115x5b1fd3bdv6298fef40342a252@mail.gmail.com> On 11/27/06, David Chelimsky wrote: > On 11/27/06, Pat Maddox wrote: > > On 11/27/06, David Chelimsky wrote: > > > As usual, I said nothing..... (accidentally hit send instead of > > > discard). Anyhow - comments below.... > > > > > > On 11/27/06, David Chelimsky wrote: > > > > On 11/27/06, aslak hellesoy wrote: > > > > > On 11/27/06, Pat Maddox wrote: > > > > > > On 11/27/06, David Chelimsky wrote: > > > > > > > On 11/27/06, Pat Maddox wrote: > > > > > > > > Another question :) > > > > > > > > > > > > > > > > When I first wrote the add_person method, my spec looked like this: > > > > > > > > > > > > > > > > specify "should accept a new person" do > > > > > > > > @user.people.size.should_be 0 > > > > > > > > @user.add_person Person.new > > > > > > > > @user.people.size.should_be 1 > > > > > > > > end > > > > > > > > > > > > > > > > That works, of course, and lets me infer that I have the new user. > > > > > > > > However I think it's ugly that I'm accessing people to verify > > > > > > > > something about the user... > > > > > > > > > > > > > > > > So then I decided to change it to this: > > > > > > > > > > > > > > > > specify "should accept a new person" do > > > > > > > > mock_person = mock("person") > > > > > > > > mock_people = mock("people") > > > > > > > > @user.should_receive(:people).and_return(mock_people) > > > > > > > > mock_people.should_receive(:<<).with(mock_person) > > > > > > > > @user.add_person mock_person > > > > > > > > end > > > > > > > > > > > > > > > > That feels like the more RSpecy way to do this, despite being longer. > > > > > > > > In both cases they dig into people (either checking the size or > > > > > > > > checking that it calls <<), but in the latter case it verifies > > > > > > > > behavior, rather than inferring it from state. Does that sound right? > > > > > > > > > > > > > > This one is tricky. There are multiple perspectives on how much > > > > > > > mocking you should do in model specs. One view is that model specs are > > > > > > > really small integration specs (model class + database). Another view > > > > > > > is that you should do what you did above, mocking out the other > > > > > > > players where possible. > > > > > > > > > > > > > > I'm leaning towards the first view - that model specs are like little > > > > > > > integration specs. My thinking is that because the way AR is designed, > > > > > > > the things you end up mocking are often internal to AR, which is a > > > > > > > huge mocking no-no (mock YOUR code, not other people's). > > > > > > > > > > > > Weren't we mocking other people's code in the controller specs as well? > > > > > > ARClass.should_receive(:find).with(1).and_return(some_mock_object) > > > > > > ARClass.should_receive(:new).with(:name => "name").and_return(other_mock_object) > > > > > > I think one *could* argue that mocking :find is closer to mocking your > > > own code (as it is a method that appears on *your* AR subclass, even > > > though it is implemented above) than mocking the collection that AR > > > makes available when you ask it for a collection property. As I said > > > before, this is very gray area, thanks to being cornered into > > > inheritance rather than composition. That sounds whiny, I know. What > > > can I say? When something is SO close to being really great, you're > > > more likely to notice its flaws than its lesser counterparts. > > > > I guess that's where I'm confused...the collection is defined on > > *your* AR subclass as well. Would you mind clarifying the difference > > you see between MyClass.find and my_instance.items? The latter case > > is even more custom because it's not automatically implemented higher > > in the heirarchy, but rather is defined only after you call "has_many > > :items" > > I'm confused too. Is it just because this particular subject is difficult, or did I confuse you more? I'm really interested in at least your initial reasoning as to why it's okay to mock Myclass.find but probably not Myclass#players. > > > > > > I'm not really sure what the difference is between mocking that out > > > > > > and mocking players. At first I thought that it's because the find > > > > > > and new calls appear in my code, but so does players <<. > > > > > > > > > > > > > > > > > > > In this case you could use this to make it feel more RSpecy without > > > > > > > mocking anything: > > > > > > > > > > > > > > specify "should accept a new person" do > > > > > > > lambda do > > > > > > > @user.add_person > > > > > > > end.should_change(@user.people.size).by(1) > > > > > > > end > > > > > > > > > > > > > > I'm not a huge fan of going after @user.people.size here, but I think > > > > > > > that @user.number_of_people might be overkill. > > > > > > > > > > > > After thinking about this some more, I think I like the other version > > > > > > with lots of mocks. To me, it boils down to what I think is a > > > > > > revelation I had last night...using the specs do define behavior, > > > > > > rather than infer it from state. > > > > > > > > > > > > The one problem I see with my example was what if the User object > > > > > > doesn't define a players method? Then the spec passes fine, but the > > > > > > code blows up of course. This would be easily solved if you ensure > > > > > > that partial mocks can only mock methods that the object already has. > > > > > > > > > > > > for example, I've got a user object that has players in this case...when I do > > > > > > user.should_receive(:players) > > > > > > then I think the should_receive call out to call > > > > > > user.respond_to?(players) before mocking the method. That seems > > > > > > reasonable to me for partial mocks - we're just substituting in some > > > > > > code for behavior that should already exist, because the existing code > > > > > > is too complex or expensive and doesn't need to be executed at the > > > > > > moment. At the very least, perhaps it could generate a warning such > > > > > > as "WARNING - 'people' not defined on user object." WDYT? > > > > > > > > > > > > > > > > That would be possible to bake into RSpec, but it would violate one of > > > > > the main principles of BDD. BDD is (among other things) a technique to > > > > > *discover* the interfaces of neighbouring objects N while speccing a > > > > > class C. And while you're speccing C, N might not even exist. > > > > > > > > > > The WARNING idea is interesting though. > > > > > > RFE [#5064] (Let mock() take a class argument) seems to be addressing > > > the similar issue. > > > > > > If we do something like this, I'd like to see it be modal. Under > > > normal spec runs it has no effect, but w/ a command line switch you > > > can get a report of what's being mocked that doesn't exist yet. I also > > > added a comment describing a vague vision (I don't really know how > > > this would work) in which if you use a class argument you could get > > > the specs to run in an integration mode in which real instances of the > > > class get substituted for the mocks, thereby allowing the specs to > > > serve as both isolation and integration specs. This is not an original > > > idea - Dan introduced something similar in JBehave, and someone on one > > > of these lists wrote about it as well some time ago. But it's worth > > > investigating, I think. > > > > I agree that it would be better to use a command line switch to report > > warnings. One problem I initially saw is when some methods are > > handled by method_missing, such as find_by_login. We wouldn't want > > warnings polluting the spec output when the method call is in fact > > valid, albeit not defined on the object itself. > > Should be ok if we use object.respond_to? For the most part. However any dynamic methods handled by method_missing, such as find_by_*, would fail. If you're interested in why, check out http://groups.google.com/group/ruby-talk-google/browse_thread/thread/082a05e0c210e1a4 But anyway, the developer can look at the "failures" and safely ignore them. > > I remember reading about the integration mode, and I think it would be > > very good. You can use the current way to drive your design well, and > > then use integration mode to ensure that the entire stack works > > properly. This would serve a different purpose from the Rails > > integration tests, which imo are to prove workflow through your > > application. > > Right. Although, this will likely get VERY complicated because you'd > have to have potentially two setups for every spec - one that uses > mocks and one that uses the real objects. It's an interesting idea, > but pretty low in priority. Integration mode would be nice, but it's not something that I'm desperately wanting at this point. I'd be happy with just the Rails integration tests. In fact maybe an integration mode wouldn't be a good - they encourage laziness (oh I don't need to write integration tests), and only test a single slice. I dunno, as you said, not a priority. > Doing something simpler, like running in a verification mode just to > get a report on what methods aren't being implemented by the classes > submitted as initialization args is more likely to happen sooner. > > So you'd do this: > > mock_thing = mock(Thing) > > When you do a normal spec run nothing happens. When you do spec > --verify_mocked (or something like that) it would produce a simple > report: > > Thing does not implement the following methods: > - blah > - ugh > - doh > - eek > > Or we could make it work more like the normal output: > > Thing should respond to the following messages: > - blah > - ugh (FAILED - NOT IMPLEMENTED) > - doh > - eek > > Any preference there? I'm not really sure...the first could be better because the output will be clean when the underlying class is fully implemented. But I guess the second provides a quick api ref? In the end I don't think it matters, but I suppose I'd go with the second one. It's more motivational - "look at all you've got done! Now just a *little* more to go..." :) Pat From noreply at rubyforge.org Tue Nov 28 09:34:20 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 28 Nov 2006 09:34:20 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6936 ] View specs don't include ApplicationHelper by default Message-ID: <20061128143420.ABC9D5241501@rubyforge.org> Bugs item #6936, was opened at 2006-11-28 15:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6936&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jens-Christian Fischer (jcfischer) Assigned to: Nobody (None) Summary: View specs don't include ApplicationHelper by default Initial Comment: def render() in view.rb includes the views helper, but does not include the Application_helper.rb inserting: @controller.add_helper("application") at line 28 in view.rb solves that. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6936&group_id=797 From noreply at rubyforge.org Tue Nov 28 17:04:51 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 28 Nov 2006 17:04:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6940 ] Expectation failure message for AR::Base.new is misleading Message-ID: <20061128220452.0F8F35241B2E@rubyforge.org> Feature Requests item #6940, was opened at 2006-11-28 15:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Expectation failure message for AR::Base.new is misleading Initial Comment: Edge Rails, 0.7.3 If you have the expectation Person.should_receive(:new).with(:name => "BJ").and_return(@mock_person) then a seemingly valid call will fail. The call would be something like get :new, :person => { :name => "BJ" } and the controller code would be Person.new params[:user] What actually gets passed into new is { "name" => "BJ } - I'm not sure if Rails is stringifying the hash keys or if RSpec is. Anyway, changing the spec to Person.should_receive(:new).with("name" => "BJ").and_return(@mock_person) works fine (notice that :name became "name"). The real problem is that when you run the first spec, it fails with Person expected :new with [{:name=>"BJ"}] once, but received it 0 times That's misleading, because :new was called, it just didn't have the right arguments. It should say something like Person expected :new with [{:name=>"BJ"}] once, but received it with [{"name"=>"BJ"}] I made a simple test case (not Rails) to demonstrate this, and to my surprise got Foo received unexpected message :foo with [1] (it should have received "1") So normally RSpec shows reasonable output, and this behavior is isolated only to Rails. It's saying that a method wasn't called, when it fact it was, but with the wrong arguments. Also, it'd be good to track down whether it's Rails or RSpec that is changing the key from :name to "name". If it's Rails doing that, then we should probably have RSpec do it under the hood as well, to match behavior. It's kind of weird to pass in { :name => "BJ" } and then be told that it wasn't received...and then find out that { "name" => "BJ" } was received instead. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 From noreply at rubyforge.org Tue Nov 28 18:51:43 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 28 Nov 2006 18:51:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6940 ] Expectation failure message for AR::Base.new is misleading Message-ID: <20061128235143.8AD295241B38@rubyforge.org> Feature Requests item #6940, was opened at 2006-11-28 17:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Expectation failure message for AR::Base.new is misleading Initial Comment: Edge Rails, 0.7.3 If you have the expectation Person.should_receive(:new).with(:name => "BJ").and_return(@mock_person) then a seemingly valid call will fail. The call would be something like get :new, :person => { :name => "BJ" } and the controller code would be Person.new params[:user] What actually gets passed into new is { "name" => "BJ } - I'm not sure if Rails is stringifying the hash keys or if RSpec is. Anyway, changing the spec to Person.should_receive(:new).with("name" => "BJ").and_return(@mock_person) works fine (notice that :name became "name"). The real problem is that when you run the first spec, it fails with Person expected :new with [{:name=>"BJ"}] once, but received it 0 times That's misleading, because :new was called, it just didn't have the right arguments. It should say something like Person expected :new with [{:name=>"BJ"}] once, but received it with [{"name"=>"BJ"}] I made a simple test case (not Rails) to demonstrate this, and to my surprise got Foo received unexpected message :foo with [1] (it should have received "1") So normally RSpec shows reasonable output, and this behavior is isolated only to Rails. It's saying that a method wasn't called, when it fact it was, but with the wrong arguments. Also, it'd be good to track down whether it's Rails or RSpec that is changing the key from :name to "name". If it's Rails doing that, then we should probably have RSpec do it under the hood as well, to match behavior. It's kind of weird to pass in { :name => "BJ" } and then be told that it wasn't received...and then find out that { "name" => "BJ" } was received instead. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-28 18:51 Message: Two things seem to be needed here. First, better error messages like you suggest. Second, we should define ActiveRecord::Base.should_receive to coerce hashes into HashWithIndifferentAccess before passing it up to RSpec core. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 From noreply at rubyforge.org Wed Nov 29 01:33:25 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 01:33:25 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6903 ] Rendering a partial in a view makes the view spec blow up Message-ID: <20061129063326.8263752409DF@rubyforge.org> Bugs item #6903, was opened at 2006-11-27 02:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6903&group_id=797 >Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Pat Maddox (pergesu) >Assigned to: David Chelimsky (dchelimsky) Summary: Rendering a partial in a view makes the view spec blow up Initial Comment: In a view spec, say you call render "people/show" and the show.rhtml file consists solely of <%= render :partial => "person", :object => @person %> the spec blows up with No rhtml, rxml, rjs or delegate template found for spec/rails/view_spec/_person in /Users/pergesu/work/givelist/trunk/config/../app/views Changing the render call to be render :partial => "people/person", :object => @person works fine. So the view spec is making something relative to the root views dir, when *I think* it should probably be relative to people in this case. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-29 06:33 Message: Fixed in trunk (rev 1174) Works for all following forms: <%= render :partial => "person", :object => @person %> <%= render :partial => "people/person", :object => @person %> <%= render :partial => "person", :collection => @people %> <%= render :partial => "people/person", :collection => @people %> ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-27 08:56 Message: Is there any chance you could reproduce this in the demo app and attach a patch so I can reproduce this easily? It would also be helpful to know what Rails/Rspec version/revision you're using. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6903&group_id=797 From noreply at rubyforge.org Wed Nov 29 01:50:32 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 01:50:32 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6936 ] View specs don't include ApplicationHelper by default Message-ID: <20061129065032.CCF6752409F2@rubyforge.org> Bugs item #6936, was opened at 2006-11-28 14:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6936&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Jens-Christian Fischer (jcfischer) >Assigned to: David Chelimsky (dchelimsky) Summary: View specs don't include ApplicationHelper by default Initial Comment: def render() in view.rb includes the views helper, but does not include the Application_helper.rb inserting: @controller.add_helper("application") at line 28 in view.rb solves that. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-29 06:50 Message: Fixed in trunk (rev 1175) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6936&group_id=797 From steve.tooke at gmail.com Wed Nov 29 10:20:05 2006 From: steve.tooke at gmail.com (Steve Tooke) Date: Wed, 29 Nov 2006 15:20:05 +0000 Subject: [rspec-devel] Calls to render and redirect in controllers should return true (rspec-on-rails) Message-ID: <78d462040611290720m9cf7b4exd1e8b8003346730e@mail.gmail.com> I think I've come across a small bug which causes the "do and return" pattern to fail with render or redirect_to inside an controller action. e.g. class MyController < ApplicationController def show_404 render( :file => "#{RAILS_ROOT}/public/404.html", :status => "404 Not Found") end end From steve.tooke at gmail.com Wed Nov 29 10:35:14 2006 From: steve.tooke at gmail.com (Steve Tooke) Date: Wed, 29 Nov 2006 15:35:14 +0000 Subject: [rspec-devel] Calls to render and redirect in controllers should return true (rspec-on-rails) Message-ID: <78d462040611290735y64370032k7c438fefdbe232bb@mail.gmail.com> Sorry for the duplicate, I managed to send the incomplete email by accident! I think I've come across a small bug which causes the "do and return" pattern to fail with render or redirect_to inside an controller action. According to changeset 462 (http://dev.rubyonrails.org/changeset/462) render and redirect_to should both return true, this does not appear to happen when running specs e.g. class MyController < ApplicationController def index @page = Page.find(:first, :condtions => ['name = ?', params[:name]]) show_404 and return unless @page render :action => :page end protected def show_404 render( :file => "#{RAILS_ROOT}/public/404.html", :status => "404 Not Found") end end ---------------- context "a GET to index with an unrecognised page" do controller_name :my_controller setup do Page.stub!(:find) end specify "should not assign a page" do get 'index', :name => 'broken' assigns['page'].should == nil end specify "should render 404 file" do controller.should_render :file => "#{RAILS_ROOT}/public/404.html", :status => "404 Not Found" get 'index', :name => 'broken' end end ------------- Both of these specs will fail with an "ActionController::DoubleRenderError", demonstrating that the return call is being ignored. Regards, Steve From dchelimsky at gmail.com Wed Nov 29 10:43:35 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 29 Nov 2006 09:43:35 -0600 Subject: [rspec-devel] Calls to render and redirect in controllers should return true (rspec-on-rails) In-Reply-To: <78d462040611290735y64370032k7c438fefdbe232bb@mail.gmail.com> References: <78d462040611290735y64370032k7c438fefdbe232bb@mail.gmail.com> Message-ID: <57c63afe0611290743p1ebfac17yc2d6b4101e1d8e46@mail.gmail.com> Would you please submit this directly to the tracker? http://rubyforge.org/tracker/?group_id=797 Thanks, David On 11/29/06, Steve Tooke wrote: > Sorry for the duplicate, I managed to send the incomplete email by accident! > > I think I've come across a small bug which causes the "do and return" > pattern to fail with render or redirect_to inside an controller > action. > > According to changeset 462 (http://dev.rubyonrails.org/changeset/462) > render and redirect_to should both return true, this does not appear > to happen when running specs > > e.g. > > class MyController < ApplicationController > > def index > @page = Page.find(:first, :condtions => ['name = ?', params[:name]]) > show_404 and return unless @page > render :action => :page > end > > protected > def show_404 > render( :file => "#{RAILS_ROOT}/public/404.html", > :status => "404 Not Found") > end > end > > ---------------- > > context "a GET to index with an unrecognised page" do > controller_name :my_controller > > setup do > Page.stub!(:find) > end > > specify "should not assign a page" do > get 'index', :name => 'broken' > assigns['page'].should == nil > end > > specify "should render 404 file" do > controller.should_render :file => "#{RAILS_ROOT}/public/404.html", > :status => "404 Not Found" > get 'index', :name => 'broken' > end > end > > ------------- > > Both of these specs will fail with an > "ActionController::DoubleRenderError", demonstrating that the return > call is being ignored. > > Regards, > Steve > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Wed Nov 29 10:58:14 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 10:58:14 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6959 ] Calls to render and redirect in controllers should return true Message-ID: <20061129155814.561735241584@rubyforge.org> Bugs item #6959, was opened at 2006-11-29 15:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6959&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Steve Tooke (stevetooke) Assigned to: Nobody (None) Summary: Calls to render and redirect in controllers should return true Initial Comment: I think I've come across a small bug which causes the "do and return" pattern to fail with render or redirect_to inside an controller action. According to changeset 462 (http://dev.rubyonrails.org/changeset/462) render and redirect_to should both return true, this does not appear to happen when running specs e.g. class PersonController < ApplicationController def show @person = Person.find(params[:id]) show_404 and return unless @person render :template => 'person/show' end protected def show_404 render( :file => "#{RAILS_ROOT}/public/404.html", :status => "404 Not Found" ) end end ------ context "attempt to show a person that doesn't exist" do controller_name :person setup do Person.stub!(:find) end specify "should not assign a person" do get 'show', :id => 'broken' assigns[:person].should == nil end specify "should render 404 file" do controller.should_render :file => "#{RAILS_ROOT}/public/404.html", :status => "404 Not Found" get 'show', :id => 'broken' end end Both of these specs will fail with an "ActionController::DoubleRenderError", demonstrating that the return call is being ignored, and that render is not returning true. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6959&group_id=797 From steve.tooke at gmail.com Wed Nov 29 11:07:02 2006 From: steve.tooke at gmail.com (Steve Tooke) Date: Wed, 29 Nov 2006 16:07:02 +0000 Subject: [rspec-devel] Calls to render and redirect in controllers should return true (rspec-on-rails) In-Reply-To: <57c63afe0611290743p1ebfac17yc2d6b4101e1d8e46@mail.gmail.com> References: <78d462040611290735y64370032k7c438fefdbe232bb@mail.gmail.com> <57c63afe0611290743p1ebfac17yc2d6b4101e1d8e46@mail.gmail.com> Message-ID: <78d462040611290807m1aada98bv2d420ce7f61b6c7b@mail.gmail.com> Submitted as Bugs item #6959 I'm trying to have a crack at fixing this, but I'm not sure exactly where I should be looking, I'm guessing its in the controller context? Cheers, Steve On 11/29/06, David Chelimsky wrote: > Would you please submit this directly to the tracker? > > http://rubyforge.org/tracker/?group_id=797 > > Thanks, > David > > On 11/29/06, Steve Tooke wrote: > > Sorry for the duplicate, I managed to send the incomplete email by accident! > > > > I think I've come across a small bug which causes the "do and return" > > pattern to fail with render or redirect_to inside an controller > > action. > > > > According to changeset 462 (http://dev.rubyonrails.org/changeset/462) > > render and redirect_to should both return true, this does not appear > > to happen when running specs > > > > e.g. > > > > class MyController < ApplicationController > > > > def index > > @page = Page.find(:first, :condtions => ['name = ?', params[:name]]) > > show_404 and return unless @page > > render :action => :page > > end > > > > protected > > def show_404 > > render( :file => "#{RAILS_ROOT}/public/404.html", > > :status => "404 Not Found") > > end > > end > > > > ---------------- > > > > context "a GET to index with an unrecognised page" do > > controller_name :my_controller > > > > setup do > > Page.stub!(:find) > > end > > > > specify "should not assign a page" do > > get 'index', :name => 'broken' > > assigns['page'].should == nil > > end > > > > specify "should render 404 file" do > > controller.should_render :file => "#{RAILS_ROOT}/public/404.html", > > :status => "404 Not Found" > > get 'index', :name => 'broken' > > end > > end > > > > ------------- > > > > Both of these specs will fail with an > > "ActionController::DoubleRenderError", demonstrating that the return > > call is being ignored. > > > > Regards, > > Steve > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Wed Nov 29 13:39:49 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 29 Nov 2006 19:39:49 +0100 Subject: [rspec-devel] bad bactraces in html_formatted.html Message-ID: <8d961d900611291039x5e424b3cuadf9283c9372783f@mail.gmail.com> dchelimsky's revision 1172 introduced full paths in html_formatted.html: /Users/david/projects/ruby/rspec/trunk/lib/spec/callback/callback_container.rb:34:in `notify' etc. The HTML formatter used to give backtraces with paths relative to the current working dir - not sure why that has changed. I haven't looked into why yet. Aslak From aslak.hellesoy at gmail.com Wed Nov 29 14:05:04 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 29 Nov 2006 20:05:04 +0100 Subject: [rspec-devel] bad bactraces in html_formatted.html In-Reply-To: <8d961d900611291039x5e424b3cuadf9283c9372783f@mail.gmail.com> References: <8d961d900611291039x5e424b3cuadf9283c9372783f@mail.gmail.com> Message-ID: <8d961d900611291105p537b7173y45068dcb752e0bed@mail.gmail.com> On 11/29/06, aslak hellesoy wrote: > dchelimsky's revision 1172 introduced full paths in html_formatted.html: > > /Users/david/projects/ruby/rspec/trunk/lib/spec/callback/callback_container.rb:34:in > `notify' > > etc. > > The HTML formatter used to give backtraces with paths relative to the > current working dir - not sure why that has changed. > > I haven't looked into why yet. > The reason why this happened is that the callback backtraces were not stripped out. I have fixed that, but the spec is still failing - probably because of character finnickiness in the HTML. I have to run.... Aslak > Aslak > From aslak.hellesoy at gmail.com Wed Nov 29 14:07:15 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 29 Nov 2006 20:07:15 +0100 Subject: [rspec-devel] bad bactraces in html_formatted.html In-Reply-To: <8d961d900611291105p537b7173y45068dcb752e0bed@mail.gmail.com> References: <8d961d900611291039x5e424b3cuadf9283c9372783f@mail.gmail.com> <8d961d900611291105p537b7173y45068dcb752e0bed@mail.gmail.com> Message-ID: <8d961d900611291107g2c19e28ay5d658b11ac48d74a@mail.gmail.com> On 11/29/06, aslak hellesoy wrote: > On 11/29/06, aslak hellesoy wrote: > > dchelimsky's revision 1172 introduced full paths in html_formatted.html: > > > > /Users/david/projects/ruby/rspec/trunk/lib/spec/callback/callback_container.rb:34:in > > `notify' > > > > etc. > > > > The HTML formatter used to give backtraces with paths relative to the > > current working dir - not sure why that has changed. > > > > I haven't looked into why yet. > > > > The reason why this happened is that the callback backtraces were not > stripped out. I have fixed that, but the spec is still failing - > probably because of character finnickiness in the HTML. I have to > run.... > OK, fixed! > Aslak > > > Aslak > > > From noreply at rubyforge.org Wed Nov 29 17:22:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 17:22:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-5064 ] Let mock() take a class argument Message-ID: <20061129222206.47DEC5241585@rubyforge.org> Feature Requests item #5064, was opened at 2006-07-14 21:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Let mock() take a class argument Initial Comment: I'd like to start my development by using: thing = mock("thing") Once I have discovered thing's interface, I'd like to switch to: thing = mock(Thing) The idea is that should_expect would fail as long as Thing doesn't implement the expected method. This is a great way to go to the next step - implementing the Thing interface. ---------------------------------------------------------------------- Comment By: Nathan Sobo (nathansobo) Date: 2006-11-29 22:22 Message: It would be helpful to continue to allow the mock method to take an optional descriptive string argument after the class argument. Also, the should_receive method could be extended with an optional modifier that would suppress warnings for messages not corresponding to methods in the mocked class, such as messages that are known to be handled by method_missing. It could look like... @mock.should_receive(:foo).and_not_warn @mock.should_receive(:foo).not_in_interface or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-12 11:25 Message: I've been thinking about this a bit and I'd like to take it even further. The thing that bugs me about this idea is that I have to keep track of which mocks are using a name and which are using the Class. What if we started creating an empty Thing class and wrote this: thing = mock(Thing) That would run if the class exists, but it not yet be defined in any detail. Then we could run specs in varying modes. Normally, they would run as they do now, with the exception that the mock expectation would read "Mock expected...." or something like that. A second mode, invoked w/ a command line option, would be that it does the checking that you talk about to make sure that all the messages being mocked have corresponding methods on the real class. A third mode would be something someone proposed on the email list - an integration mode. This would require some additional setup and I'm not sure what that looks like (perhaps an integration_setup block?), but the idea is that you could run all of the same specs using real objects instead of the mocks. You wouldn't have to write separate integration specs. This is something Dan described about JBehave when he and I spoke at Agile 06. When you run JBehave, it tells you how many mocks are still being used. The idea there is that you should remove them over time - just use them to get you there, but use the real objects as they come to be. When there are no mocks in the run and all the specs pass, you're done! The nice thing about having a CL option to run them this way is that you can monitor your progress towards "done", but you can also run the specs in isolation normally. This gives you the benefits of both worlds - isolation and integration. In fact the mock modes could be isolation (default), verification and integration. That has some nice symmetry to it. Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 From noreply at rubyforge.org Wed Nov 29 18:06:21 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 18:06:21 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6971 ] and_yield does not work when the arity is -1 Message-ID: <20061129230622.12A0B5241BC2@rubyforge.org> Bugs item #6971, was opened at 2006-11-29 15:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6971&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: and_yield does not work when the arity is -1 Initial Comment: def foo(bar) bar.call {|*args|} end bar = mock("bar) bar.should_receive(:call).and_yield foo(bar) # Mock 'bar' yielded || to block with arity of -1 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6971&group_id=797 From noreply at rubyforge.org Wed Nov 29 18:27:08 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 18:27:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-5064 ] Let mock() take a class argument Message-ID: <20061129232708.453DD524162D@rubyforge.org> Feature Requests item #5064, was opened at 2006-07-14 15:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Let mock() take a class argument Initial Comment: I'd like to start my development by using: thing = mock("thing") Once I have discovered thing's interface, I'd like to switch to: thing = mock(Thing) The idea is that should_expect would fail as long as Thing doesn't implement the expected method. This is a great way to go to the next step - implementing the Thing interface. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-29 16:27 Message: I've been thinking about this a lot over the past couple days. We use rspec and mocks to specify the behavior of and interaction between objects. When we mock behavior, all we care about is the interface - concrete classes shouldn't matter at all. The more I think about it the less I like it. Things like integration mode test behavior of the system, rather than of the objects themselves, and I think that's something that should be separate from the standard specifications. Whether that's something that should be a part of RSpec, I'm not sure...but I am certain that testing the system behavior should be separate from specifying object behavior and interactions. ---------------------------------------------------------------------- Comment By: Nathan Sobo (nathansobo) Date: 2006-11-29 15:22 Message: It would be helpful to continue to allow the mock method to take an optional descriptive string argument after the class argument. Also, the should_receive method could be extended with an optional modifier that would suppress warnings for messages not corresponding to methods in the mocked class, such as messages that are known to be handled by method_missing. It could look like... @mock.should_receive(:foo).and_not_warn @mock.should_receive(:foo).not_in_interface or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-12 05:25 Message: I've been thinking about this a bit and I'd like to take it even further. The thing that bugs me about this idea is that I have to keep track of which mocks are using a name and which are using the Class. What if we started creating an empty Thing class and wrote this: thing = mock(Thing) That would run if the class exists, but it not yet be defined in any detail. Then we could run specs in varying modes. Normally, they would run as they do now, with the exception that the mock expectation would read "Mock expected...." or something like that. A second mode, invoked w/ a command line option, would be that it does the checking that you talk about to make sure that all the messages being mocked have corresponding methods on the real class. A third mode would be something someone proposed on the email list - an integration mode. This would require some additional setup and I'm not sure what that looks like (perhaps an integration_setup block?), but the idea is that you could run all of the same specs using real objects instead of the mocks. You wouldn't have to write separate integration specs. This is something Dan described about JBehave when he and I spoke at Agile 06. When you run JBehave, it tells you how many mocks are still being used. The idea there is that you should remove them over time - just use them to get you there, but use the real objects as they come to be. When there are no mocks in the run and all the specs pass, you're done! The nice thing about having a CL option to run them this way is that you can monitor your progress towards "done", but you can also run the specs in isolation normally. This gives you the benefits of both worlds - isolation and integration. In fact the mock modes could be isolation (default), verification and integration. That has some nice symmetry to it. Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 From noreply at rubyforge.org Wed Nov 29 19:15:07 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 19:15:07 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-5064 ] Let mock() take a class argument Message-ID: <20061130001507.DF1245241BDF@rubyforge.org> Feature Requests item #5064, was opened at 2006-07-14 21:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Let mock() take a class argument Initial Comment: I'd like to start my development by using: thing = mock("thing") Once I have discovered thing's interface, I'd like to switch to: thing = mock(Thing) The idea is that should_expect would fail as long as Thing doesn't implement the expected method. This is a great way to go to the next step - implementing the Thing interface. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 00:15 Message: There are a lot of different ideas expressed in this thread. The thing that would be the most simple and, in my view, the most useful, would be Aslak's initial request BUT instead of failing you'd get feedback. We wouldn't use this for integration at all. So, if you do this: thing = mock('thing') you get things as they are now. If you do this: thing = mock(Thing) you get things as they are now, w/ failure messages reading 'Thing'. Then, if you CHOOSE to, you can run the spec command w/ a switch that simply provides a report of methods that are being called on the mock Thing that Thing will not respond to. This can be very helpful when doing a top-down style of development in which mocks are used to help you discover the interfaces of the collaborators. In a statically typed language like java, you get this benefit automatically because you have to add methods to a java interface as you discover them. This facility in rspec would give you that little extra edge. The whole doubling as integration idea is probably silly. Cheers, David ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-29 23:27 Message: I've been thinking about this a lot over the past couple days. We use rspec and mocks to specify the behavior of and interaction between objects. When we mock behavior, all we care about is the interface - concrete classes shouldn't matter at all. The more I think about it the less I like it. Things like integration mode test behavior of the system, rather than of the objects themselves, and I think that's something that should be separate from the standard specifications. Whether that's something that should be a part of RSpec, I'm not sure...but I am certain that testing the system behavior should be separate from specifying object behavior and interactions. ---------------------------------------------------------------------- Comment By: Nathan Sobo (nathansobo) Date: 2006-11-29 22:22 Message: It would be helpful to continue to allow the mock method to take an optional descriptive string argument after the class argument. Also, the should_receive method could be extended with an optional modifier that would suppress warnings for messages not corresponding to methods in the mocked class, such as messages that are known to be handled by method_missing. It could look like... @mock.should_receive(:foo).and_not_warn @mock.should_receive(:foo).not_in_interface or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-12 11:25 Message: I've been thinking about this a bit and I'd like to take it even further. The thing that bugs me about this idea is that I have to keep track of which mocks are using a name and which are using the Class. What if we started creating an empty Thing class and wrote this: thing = mock(Thing) That would run if the class exists, but it not yet be defined in any detail. Then we could run specs in varying modes. Normally, they would run as they do now, with the exception that the mock expectation would read "Mock expected...." or something like that. A second mode, invoked w/ a command line option, would be that it does the checking that you talk about to make sure that all the messages being mocked have corresponding methods on the real class. A third mode would be something someone proposed on the email list - an integration mode. This would require some additional setup and I'm not sure what that looks like (perhaps an integration_setup block?), but the idea is that you could run all of the same specs using real objects instead of the mocks. You wouldn't have to write separate integration specs. This is something Dan described about JBehave when he and I spoke at Agile 06. When you run JBehave, it tells you how many mocks are still being used. The idea there is that you should remove them over time - just use them to get you there, but use the real objects as they come to be. When there are no mocks in the run and all the specs pass, you're done! The nice thing about having a CL option to run them this way is that you can monitor your progress towards "done", but you can also run the specs in isolation normally. This gives you the benefits of both worlds - isolation and integration. In fact the mock modes could be isolation (default), verification and integration. That has some nice symmetry to it. Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 From noreply at rubyforge.org Wed Nov 29 22:15:00 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 22:15:00 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6978 ] mock should tell you the expected and actual args when receiving the right message with the wrong args Message-ID: <20061130031501.133AF5241C0E@rubyforge.org> Feature Requests item #6978, was opened at 2006-11-30 03:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6978&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: mock should tell you the expected and actual args when receiving the right message with the wrong args Initial Comment: specify "..." do mock = mock('test mock') mock.should_receive(:message).with(1,2,3) mock.message(2,3,4) end will produce the following output: Mock 'test mock' received unexpected message :something with [2,3,4] It doesn't tell you what it actually got, which would be very helpful in understanding what went wrong. It should read: Mock 'test mock' expected :message with [1,2,3] but received it with [2,3,4] ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6978&group_id=797 From noreply at rubyforge.org Wed Nov 29 22:15:52 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 22:15:52 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6940 ] Expectation failure message for AR::Base.new is misleading Message-ID: <20061130031552.EF22D5241C0F@rubyforge.org> Feature Requests item #6940, was opened at 2006-11-28 22:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Expectation failure message for AR::Base.new is misleading Initial Comment: Edge Rails, 0.7.3 If you have the expectation Person.should_receive(:new).with(:name => "BJ").and_return(@mock_person) then a seemingly valid call will fail. The call would be something like get :new, :person => { :name => "BJ" } and the controller code would be Person.new params[:user] What actually gets passed into new is { "name" => "BJ } - I'm not sure if Rails is stringifying the hash keys or if RSpec is. Anyway, changing the spec to Person.should_receive(:new).with("name" => "BJ").and_return(@mock_person) works fine (notice that :name became "name"). The real problem is that when you run the first spec, it fails with Person expected :new with [{:name=>"BJ"}] once, but received it 0 times That's misleading, because :new was called, it just didn't have the right arguments. It should say something like Person expected :new with [{:name=>"BJ"}] once, but received it with [{"name"=>"BJ"}] I made a simple test case (not Rails) to demonstrate this, and to my surprise got Foo received unexpected message :foo with [1] (it should have received "1") So normally RSpec shows reasonable output, and this behavior is isolated only to Rails. It's saying that a method wasn't called, when it fact it was, but with the wrong arguments. Also, it'd be good to track down whether it's Rails or RSpec that is changing the key from :name to "name". If it's Rails doing that, then we should probably have RSpec do it under the hood as well, to match behavior. It's kind of weird to pass in { :name => "BJ" } and then be told that it wasn't received...and then find out that { "name" => "BJ" } was received instead. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 03:15 Message: I added [#6978] to address the mock messaging, so we'll leave this open for the stringy keys. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-28 23:51 Message: Two things seem to be needed here. First, better error messages like you suggest. Second, we should define ActiveRecord::Base.should_receive to coerce hashes into HashWithIndifferentAccess before passing it up to RSpec core. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 From noreply at rubyforge.org Wed Nov 29 22:25:13 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 22:25:13 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6978 ] mock should tell you the expected and actual args when receiving the right message with the wrong args Message-ID: <20061130032513.8FCB55241C0D@rubyforge.org> Feature Requests item #6978, was opened at 2006-11-30 03:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6978&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: mock should tell you the expected and actual args when receiving the right message with the wrong args Initial Comment: specify "..." do mock = mock('test mock') mock.should_receive(:message).with(1,2,3) mock.message(2,3,4) end will produce the following output: Mock 'test mock' received unexpected message :something with [2,3,4] It doesn't tell you what it actually got, which would be very helpful in understanding what went wrong. It should read: Mock 'test mock' expected :message with [1,2,3] but received it with [2,3,4] ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 03:25 Message: Fixed in trunk (rev 6978) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6978&group_id=797 From noreply at rubyforge.org Wed Nov 29 23:06:19 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 23:06:19 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-5064 ] Let mock() take a class argument Message-ID: <20061130040619.2745A5241C2D@rubyforge.org> Feature Requests item #5064, was opened at 2006-07-14 15:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Let mock() take a class argument Initial Comment: I'd like to start my development by using: thing = mock("thing") Once I have discovered thing's interface, I'd like to switch to: thing = mock(Thing) The idea is that should_expect would fail as long as Thing doesn't implement the expected method. This is a great way to go to the next step - implementing the Thing interface. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-29 21:06 Message: As I mentioned earlier, the problem with this is that the specs will now be coupled to a concrete class. That is a bad direction for us to take RSpec, considering that it's (imo) the best tool for driving development. What about instead of passing in a class, we just have a command line switch that shows each mock's interface? rspec --show-interfaces thing_spec.rb produces: Thing - foo - bar - baz I know that's not quite what you want, but it will easily let you see if your class conforms to the interface. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-29 17:15 Message: There are a lot of different ideas expressed in this thread. The thing that would be the most simple and, in my view, the most useful, would be Aslak's initial request BUT instead of failing you'd get feedback. We wouldn't use this for integration at all. So, if you do this: thing = mock('thing') you get things as they are now. If you do this: thing = mock(Thing) you get things as they are now, w/ failure messages reading 'Thing'. Then, if you CHOOSE to, you can run the spec command w/ a switch that simply provides a report of methods that are being called on the mock Thing that Thing will not respond to. This can be very helpful when doing a top-down style of development in which mocks are used to help you discover the interfaces of the collaborators. In a statically typed language like java, you get this benefit automatically because you have to add methods to a java interface as you discover them. This facility in rspec would give you that little extra edge. The whole doubling as integration idea is probably silly. Cheers, David ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-29 16:27 Message: I've been thinking about this a lot over the past couple days. We use rspec and mocks to specify the behavior of and interaction between objects. When we mock behavior, all we care about is the interface - concrete classes shouldn't matter at all. The more I think about it the less I like it. Things like integration mode test behavior of the system, rather than of the objects themselves, and I think that's something that should be separate from the standard specifications. Whether that's something that should be a part of RSpec, I'm not sure...but I am certain that testing the system behavior should be separate from specifying object behavior and interactions. ---------------------------------------------------------------------- Comment By: Nathan Sobo (nathansobo) Date: 2006-11-29 15:22 Message: It would be helpful to continue to allow the mock method to take an optional descriptive string argument after the class argument. Also, the should_receive method could be extended with an optional modifier that would suppress warnings for messages not corresponding to methods in the mocked class, such as messages that are known to be handled by method_missing. It could look like... @mock.should_receive(:foo).and_not_warn @mock.should_receive(:foo).not_in_interface or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-12 05:25 Message: I've been thinking about this a bit and I'd like to take it even further. The thing that bugs me about this idea is that I have to keep track of which mocks are using a name and which are using the Class. What if we started creating an empty Thing class and wrote this: thing = mock(Thing) That would run if the class exists, but it not yet be defined in any detail. Then we could run specs in varying modes. Normally, they would run as they do now, with the exception that the mock expectation would read "Mock expected...." or something like that. A second mode, invoked w/ a command line option, would be that it does the checking that you talk about to make sure that all the messages being mocked have corresponding methods on the real class. A third mode would be something someone proposed on the email list - an integration mode. This would require some additional setup and I'm not sure what that looks like (perhaps an integration_setup block?), but the idea is that you could run all of the same specs using real objects instead of the mocks. You wouldn't have to write separate integration specs. This is something Dan described about JBehave when he and I spoke at Agile 06. When you run JBehave, it tells you how many mocks are still being used. The idea there is that you should remove them over time - just use them to get you there, but use the real objects as they come to be. When there are no mocks in the run and all the specs pass, you're done! The nice thing about having a CL option to run them this way is that you can monitor your progress towards "done", but you can also run the specs in isolation normally. This gives you the benefits of both worlds - isolation and integration. In fact the mock modes could be isolation (default), verification and integration. That has some nice symmetry to it. Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 From noreply at rubyforge.org Wed Nov 29 23:13:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 23:13:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-5064 ] Let mock() take a class argument Message-ID: <20061130041313.258E25241C2B@rubyforge.org> Feature Requests item #5064, was opened at 2006-07-14 15:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Helles?y (aslak_hellesoy) Assigned to: Nobody (None) Summary: Let mock() take a class argument Initial Comment: I'd like to start my development by using: thing = mock("thing") Once I have discovered thing's interface, I'd like to switch to: thing = mock(Thing) The idea is that should_expect would fail as long as Thing doesn't implement the expected method. This is a great way to go to the next step - implementing the Thing interface. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-29 21:13 Message: ooh! I just had a decent (I think) idea. Instead of passing in a class, we can check to see if a class implement's the interface we've discovered on a particular mock. For example ... specs specify "Thing should implement foo, bar, baz" do Thing.should_implement(@mock_thing) end should_implement would be really simple. Just loop through all the mocked/stubbed methods on @mock_thing and see if Thing responds to each one. If Thing doesn't conform to the interface, the output is something like 'Thing should implement foo, bar, baz' FAILED Thing doesn't implement - foo - baz Since Ruby is dynamically typed, we lose a little bit (in some cases, perhaps such as this) where we don't have a defined interface. But I think it's dangerous to let the spec code get coupled to concrete collaborator classes. We can take advantage of Ruby here by verifying that a class satisfies the same interface as a mock we're using. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-29 21:06 Message: As I mentioned earlier, the problem with this is that the specs will now be coupled to a concrete class. That is a bad direction for us to take RSpec, considering that it's (imo) the best tool for driving development. What about instead of passing in a class, we just have a command line switch that shows each mock's interface? rspec --show-interfaces thing_spec.rb produces: Thing - foo - bar - baz I know that's not quite what you want, but it will easily let you see if your class conforms to the interface. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-29 17:15 Message: There are a lot of different ideas expressed in this thread. The thing that would be the most simple and, in my view, the most useful, would be Aslak's initial request BUT instead of failing you'd get feedback. We wouldn't use this for integration at all. So, if you do this: thing = mock('thing') you get things as they are now. If you do this: thing = mock(Thing) you get things as they are now, w/ failure messages reading 'Thing'. Then, if you CHOOSE to, you can run the spec command w/ a switch that simply provides a report of methods that are being called on the mock Thing that Thing will not respond to. This can be very helpful when doing a top-down style of development in which mocks are used to help you discover the interfaces of the collaborators. In a statically typed language like java, you get this benefit automatically because you have to add methods to a java interface as you discover them. This facility in rspec would give you that little extra edge. The whole doubling as integration idea is probably silly. Cheers, David ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-29 16:27 Message: I've been thinking about this a lot over the past couple days. We use rspec and mocks to specify the behavior of and interaction between objects. When we mock behavior, all we care about is the interface - concrete classes shouldn't matter at all. The more I think about it the less I like it. Things like integration mode test behavior of the system, rather than of the objects themselves, and I think that's something that should be separate from the standard specifications. Whether that's something that should be a part of RSpec, I'm not sure...but I am certain that testing the system behavior should be separate from specifying object behavior and interactions. ---------------------------------------------------------------------- Comment By: Nathan Sobo (nathansobo) Date: 2006-11-29 15:22 Message: It would be helpful to continue to allow the mock method to take an optional descriptive string argument after the class argument. Also, the should_receive method could be extended with an optional modifier that would suppress warnings for messages not corresponding to methods in the mocked class, such as messages that are known to be handled by method_missing. It could look like... @mock.should_receive(:foo).and_not_warn @mock.should_receive(:foo).not_in_interface or something. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-12 05:25 Message: I've been thinking about this a bit and I'd like to take it even further. The thing that bugs me about this idea is that I have to keep track of which mocks are using a name and which are using the Class. What if we started creating an empty Thing class and wrote this: thing = mock(Thing) That would run if the class exists, but it not yet be defined in any detail. Then we could run specs in varying modes. Normally, they would run as they do now, with the exception that the mock expectation would read "Mock expected...." or something like that. A second mode, invoked w/ a command line option, would be that it does the checking that you talk about to make sure that all the messages being mocked have corresponding methods on the real class. A third mode would be something someone proposed on the email list - an integration mode. This would require some additional setup and I'm not sure what that looks like (perhaps an integration_setup block?), but the idea is that you could run all of the same specs using real objects instead of the mocks. You wouldn't have to write separate integration specs. This is something Dan described about JBehave when he and I spoke at Agile 06. When you run JBehave, it tells you how many mocks are still being used. The idea there is that you should remove them over time - just use them to get you there, but use the real objects as they come to be. When there are no mocks in the run and all the specs pass, you're done! The nice thing about having a CL option to run them this way is that you can monitor your progress towards "done", but you can also run the specs in isolation normally. This gives you the benefits of both worlds - isolation and integration. In fact the mock modes could be isolation (default), verification and integration. That has some nice symmetry to it. Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 From noreply at rubyforge.org Wed Nov 29 23:15:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 23:15:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6940 ] Expectation failure message for AR::Base.new is misleading Message-ID: <20061130041505.6EAD45241C16@rubyforge.org> Feature Requests item #6940, was opened at 2006-11-28 22:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Expectation failure message for AR::Base.new is misleading Initial Comment: Edge Rails, 0.7.3 If you have the expectation Person.should_receive(:new).with(:name => "BJ").and_return(@mock_person) then a seemingly valid call will fail. The call would be something like get :new, :person => { :name => "BJ" } and the controller code would be Person.new params[:user] What actually gets passed into new is { "name" => "BJ } - I'm not sure if Rails is stringifying the hash keys or if RSpec is. Anyway, changing the spec to Person.should_receive(:new).with("name" => "BJ").and_return(@mock_person) works fine (notice that :name became "name"). The real problem is that when you run the first spec, it fails with Person expected :new with [{:name=>"BJ"}] once, but received it 0 times That's misleading, because :new was called, it just didn't have the right arguments. It should say something like Person expected :new with [{:name=>"BJ"}] once, but received it with [{"name"=>"BJ"}] I made a simple test case (not Rails) to demonstrate this, and to my surprise got Foo received unexpected message :foo with [1] (it should have received "1") So normally RSpec shows reasonable output, and this behavior is isolated only to Rails. It's saying that a method wasn't called, when it fact it was, but with the wrong arguments. Also, it'd be good to track down whether it's Rails or RSpec that is changing the key from :name to "name". If it's Rails doing that, then we should probably have RSpec do it under the hood as well, to match behavior. It's kind of weird to pass in { :name => "BJ" } and then be told that it wasn't received...and then find out that { "name" => "BJ" } was received instead. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 04:15 Message: I'm on the fence about the stringy keys. Rails does this conversion, and the mock doesn't know it's being called from a rails spec. Now the mock messaging will give you this: Person expected :new with [{:name=>"BJ"}] once, but received it with [{"name"=>"BJ"}] Is that sufficient? I think it is. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 03:15 Message: I added [#6978] to address the mock messaging, so we'll leave this open for the stringy keys. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-28 23:51 Message: Two things seem to be needed here. First, better error messages like you suggest. Second, we should define ActiveRecord::Base.should_receive to coerce hashes into HashWithIndifferentAccess before passing it up to RSpec core. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 From noreply at rubyforge.org Wed Nov 29 23:50:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 29 Nov 2006 23:50:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6940 ] Expectation failure message for AR::Base.new is misleading Message-ID: <20061130045012.D5F975241C24@rubyforge.org> Feature Requests item #6940, was opened at 2006-11-28 15:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Expectation failure message for AR::Base.new is misleading Initial Comment: Edge Rails, 0.7.3 If you have the expectation Person.should_receive(:new).with(:name => "BJ").and_return(@mock_person) then a seemingly valid call will fail. The call would be something like get :new, :person => { :name => "BJ" } and the controller code would be Person.new params[:user] What actually gets passed into new is { "name" => "BJ } - I'm not sure if Rails is stringifying the hash keys or if RSpec is. Anyway, changing the spec to Person.should_receive(:new).with("name" => "BJ").and_return(@mock_person) works fine (notice that :name became "name"). The real problem is that when you run the first spec, it fails with Person expected :new with [{:name=>"BJ"}] once, but received it 0 times That's misleading, because :new was called, it just didn't have the right arguments. It should say something like Person expected :new with [{:name=>"BJ"}] once, but received it with [{"name"=>"BJ"}] I made a simple test case (not Rails) to demonstrate this, and to my surprise got Foo received unexpected message :foo with [1] (it should have received "1") So normally RSpec shows reasonable output, and this behavior is isolated only to Rails. It's saying that a method wasn't called, when it fact it was, but with the wrong arguments. Also, it'd be good to track down whether it's Rails or RSpec that is changing the key from :name to "name". If it's Rails doing that, then we should probably have RSpec do it under the hood as well, to match behavior. It's kind of weird to pass in { :name => "BJ" } and then be told that it wasn't received...and then find out that { "name" => "BJ" } was received instead. ---------------------------------------------------------------------- >Comment By: Pat Maddox (pergesu) Date: 2006-11-29 21:50 Message: That's fine by me. Just need to see the difference between what it expected and what it got ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-29 21:15 Message: I'm on the fence about the stringy keys. Rails does this conversion, and the mock doesn't know it's being called from a rails spec. Now the mock messaging will give you this: Person expected :new with [{:name=>"BJ"}] once, but received it with [{"name"=>"BJ"}] Is that sufficient? I think it is. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-29 20:15 Message: I added [#6978] to address the mock messaging, so we'll leave this open for the stringy keys. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-28 16:51 Message: Two things seem to be needed here. First, better error messages like you suggest. Second, we should define ActiveRecord::Base.should_receive to coerce hashes into HashWithIndifferentAccess before passing it up to RSpec core. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 From noreply at rubyforge.org Thu Nov 30 00:16:17 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 00:16:17 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6940 ] Expectation failure message for AR::Base.new is misleading Message-ID: <20061130051618.6D5AA5240958@rubyforge.org> Feature Requests item #6940, was opened at 2006-11-28 22:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Expectation failure message for AR::Base.new is misleading Initial Comment: Edge Rails, 0.7.3 If you have the expectation Person.should_receive(:new).with(:name => "BJ").and_return(@mock_person) then a seemingly valid call will fail. The call would be something like get :new, :person => { :name => "BJ" } and the controller code would be Person.new params[:user] What actually gets passed into new is { "name" => "BJ } - I'm not sure if Rails is stringifying the hash keys or if RSpec is. Anyway, changing the spec to Person.should_receive(:new).with("name" => "BJ").and_return(@mock_person) works fine (notice that :name became "name"). The real problem is that when you run the first spec, it fails with Person expected :new with [{:name=>"BJ"}] once, but received it 0 times That's misleading, because :new was called, it just didn't have the right arguments. It should say something like Person expected :new with [{:name=>"BJ"}] once, but received it with [{"name"=>"BJ"}] I made a simple test case (not Rails) to demonstrate this, and to my surprise got Foo received unexpected message :foo with [1] (it should have received "1") So normally RSpec shows reasonable output, and this behavior is isolated only to Rails. It's saying that a method wasn't called, when it fact it was, but with the wrong arguments. Also, it'd be good to track down whether it's Rails or RSpec that is changing the key from :name to "name". If it's Rails doing that, then we should probably have RSpec do it under the hood as well, to match behavior. It's kind of weird to pass in { :name => "BJ" } and then be told that it wasn't received...and then find out that { "name" => "BJ" } was received instead. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 05:16 Message: Cool. Thanks. Closing this now. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2006-11-30 04:50 Message: That's fine by me. Just need to see the difference between what it expected and what it got ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 04:15 Message: I'm on the fence about the stringy keys. Rails does this conversion, and the mock doesn't know it's being called from a rails spec. Now the mock messaging will give you this: Person expected :new with [{:name=>"BJ"}] once, but received it with [{"name"=>"BJ"}] Is that sufficient? I think it is. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 03:15 Message: I added [#6978] to address the mock messaging, so we'll leave this open for the stringy keys. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-11-28 23:51 Message: Two things seem to be needed here. First, better error messages like you suggest. Second, we should define ActiveRecord::Base.should_receive to coerce hashes into HashWithIndifferentAccess before passing it up to RSpec core. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6940&group_id=797 From noreply at rubyforge.org Thu Nov 30 00:34:43 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 00:34:43 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6980 ] Can't set expectations on Rails association proxy object Message-ID: <20061130053443.B608D52409A6@rubyforge.org> Bugs item #6980, was opened at 2006-11-29 22:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6980&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can't set expectations on Rails association proxy object Initial Comment: edge rails, 0.7.3 context "Given a call to destroy, a Person" do setup do @person = Person.create :name => "Me", :user_id => 1 @person.add_item Item.new(:name => "Item") end specify "should destroy its items" do @person.items.should_receive(:delete_all) @person.destroy end end This assumes the following config in Person.rb has_many :items, :dependent => :delete_all The failure is: NoMethodError in 'Given a call to destroy, a Person should destroy its items' undefined method `receive?' for Item:Class My best guess is that since items is a proxy class defined at runtime, the should_receive method isn't getting mixed into it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6980&group_id=797 From noreply at rubyforge.org Thu Nov 30 01:21:58 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 01:21:58 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6981 ] helper method is not available in partial template. Message-ID: <20061130062159.DC13452409C8@rubyforge.org> Bugs item #6981, was opened at 2006-11-30 15:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6981&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Kyosuke MOROHASHI (moro) Assigned to: Nobody (None) Summary: helper method is not available in partial template. Initial Comment: a helper method called in partially rendered in other view template does not work. for example, test for the view below is fails with message "undefined local variable or method `person_address_text_field' for #<#:0x35e2a38>" Index: vendor/rspec_on_rails/app/views/person/_person.rhtml =================================================================== --- vendor/rspec_on_rails/app/views/person/_person.rhtml (revision 1180) +++ vendor/rspec_on_rails/app/views/person/_person.rhtml (working copy)@@ -1 +1,2 @@ -
  • <%=person.name %>
    • +
  • <%= person.name %><%= person_address_text_field %>
    • ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6981&group_id=797 From contact at lukeredpath.co.uk Thu Nov 30 07:25:54 2006 From: contact at lukeredpath.co.uk (Luke Redpath) Date: Thu, 30 Nov 2006 12:25:54 +0000 Subject: [rspec-devel] Updated HTML formatter template Message-ID: I've done a bit of work on the current RSpec HTML formatter template - I've changed the stylesheet and played around with the markup a bit to make it a bit more semantic (I've opted for definition lists for the specs). You can view it here: http://uploads.lukeredpath.co.uk/rspec.html It still needs a bit of tweaking, but if nobody has any objections, I'll roll this into the trunk. Cheers Luke From steve.tooke at gmail.com Thu Nov 30 07:50:38 2006 From: steve.tooke at gmail.com (Steve Tooke) Date: Thu, 30 Nov 2006 12:50:38 +0000 Subject: [rspec-devel] Calls to render and redirect in controllers should return true (rspec-on-rails) In-Reply-To: <78d462040611290807m1aada98bv2d420ce7f61b6c7b@mail.gmail.com> References: <78d462040611290735y64370032k7c438fefdbe232bb@mail.gmail.com> <57c63afe0611290743p1ebfac17yc2d6b4101e1d8e46@mail.gmail.com> <78d462040611290807m1aada98bv2d420ce7f61b6c7b@mail.gmail.com> Message-ID: <78d462040611300450i312adddcw976f43b8f1680705@mail.gmail.com> Could this be because I'm isolating the controllers from the views, so nothing is actually being rendered - hence why render is returning nil? On 11/29/06, Steve Tooke wrote: > Submitted as Bugs item #6959 > > I'm trying to have a crack at fixing this, but I'm not sure exactly > where I should be looking, I'm guessing its in the controller context? > > Cheers, > Steve > > On 11/29/06, David Chelimsky wrote: > > Would you please submit this directly to the tracker? > > > > http://rubyforge.org/tracker/?group_id=797 > > > > Thanks, > > David > > > > On 11/29/06, Steve Tooke wrote: > > > Sorry for the duplicate, I managed to send the incomplete email by accident! > > > > > > I think I've come across a small bug which causes the "do and return" > > > pattern to fail with render or redirect_to inside an controller > > > action. > > > > > > According to changeset 462 (http://dev.rubyonrails.org/changeset/462) > > > render and redirect_to should both return true, this does not appear > > > to happen when running specs > > > > > > e.g. > > > > > > class MyController < ApplicationController > > > > > > def index > > > @page = Page.find(:first, :condtions => ['name = ?', params[:name]]) > > > show_404 and return unless @page > > > render :action => :page > > > end > > > > > > protected > > > def show_404 > > > render( :file => "#{RAILS_ROOT}/public/404.html", > > > :status => "404 Not Found") > > > end > > > end > > > > > > ---------------- > > > > > > context "a GET to index with an unrecognised page" do > > > controller_name :my_controller > > > > > > setup do > > > Page.stub!(:find) > > > end > > > > > > specify "should not assign a page" do > > > get 'index', :name => 'broken' > > > assigns['page'].should == nil > > > end > > > > > > specify "should render 404 file" do > > > controller.should_render :file => "#{RAILS_ROOT}/public/404.html", > > > :status => "404 Not Found" > > > get 'index', :name => 'broken' > > > end > > > end > > > > > > ------------- > > > > > > Both of these specs will fail with an > > > "ActionController::DoubleRenderError", demonstrating that the return > > > call is being ignored. > > > > > > Regards, > > > Steve > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From aslak.hellesoy at gmail.com Thu Nov 30 07:58:47 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 30 Nov 2006 13:58:47 +0100 Subject: [rspec-devel] Updated HTML formatter template In-Reply-To: References: Message-ID: <8d961d900611300458v10fa9d76g58cc414970d2a105@mail.gmail.com> On 11/30/06, Luke Redpath wrote: > I've done a bit of work on the current RSpec HTML formatter template > - I've changed the stylesheet and played around with the markup a bit > to make it a bit more semantic (I've opted for definition lists for > the specs). You can view it here: > > http://uploads.lukeredpath.co.uk/rspec.html > Looks great in general but... > It still needs a bit of tweaking, but if nobody has any objections, > I'll roll this into the trunk. > people generally associate red with failure and green with success (at least in the software testing domain). Aren't these colours at odds with the common conventions? My initial reaction was "This is all failures". Can you show us one that has both passing and failing specs? Cheers, Aslak > Cheers > Luke > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Thu Nov 30 08:13:49 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 08:13:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6981 ] helper method is not available in partial template. Message-ID: <20061130131349.82D795241242@rubyforge.org> Bugs item #6981, was opened at 2006-11-30 06:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6981&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Kyosuke MOROHASHI (moro) >Assigned to: David Chelimsky (dchelimsky) Summary: helper method is not available in partial template. Initial Comment: a helper method called in partially rendered in other view template does not work. for example, test for the view below is fails with message "undefined local variable or method `person_address_text_field' for #<#:0x35e2a38>" Index: vendor/rspec_on_rails/app/views/person/_person.rhtml =================================================================== --- vendor/rspec_on_rails/app/views/person/_person.rhtml (revision 1180) +++ vendor/rspec_on_rails/app/views/person/_person.rhtml (working copy)@@ -1 +1,2 @@ -
  • <%=person.name %>
    • +
  • <%= person.name %><%= person_address_text_field %>
    • ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 13:13 Message: Fixed in trunk (rev 1181) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6981&group_id=797 From dchelimsky at gmail.com Thu Nov 30 08:17:57 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 30 Nov 2006 08:17:57 -0500 Subject: [rspec-devel] Updated HTML formatter template In-Reply-To: <8d961d900611300458v10fa9d76g58cc414970d2a105@mail.gmail.com> References: <8d961d900611300458v10fa9d76g58cc414970d2a105@mail.gmail.com> Message-ID: <57c63afe0611300517q1f8e9902ib1aa949f32953fdf@mail.gmail.com> On 11/30/06, aslak hellesoy wrote: > On 11/30/06, Luke Redpath wrote: > > I've done a bit of work on the current RSpec HTML formatter template > > - I've changed the stylesheet and played around with the markup a bit > > to make it a bit more semantic (I've opted for definition lists for > > the specs). You can view it here: > > > > http://uploads.lukeredpath.co.uk/rspec.html > > > > Looks great in general but... > > > It still needs a bit of tweaking, but if nobody has any objections, > > I'll roll this into the trunk. > > > > people generally associate red with failure and green with success (at > least in the software testing domain). Aren't these colours at odds > with the common conventions? My initial reaction was "This is all > failures". > Agreed. The feel is very nice but the red does imply failure. Also - I think that w/ hundreds of specs, this page will get quite long. I'd like to see something with slightly smaller fonts and less space without sacrificing the nice look. One can wish, right? Thanks Luke, David > Can you show us one that has both passing and failing specs? > > Cheers, > Aslak > > > Cheers > > Luke > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Thu Nov 30 08:19:34 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 30 Nov 2006 08:19:34 -0500 Subject: [rspec-devel] Calls to render and redirect in controllers should return true (rspec-on-rails) In-Reply-To: <78d462040611300450i312adddcw976f43b8f1680705@mail.gmail.com> References: <78d462040611290735y64370032k7c438fefdbe232bb@mail.gmail.com> <57c63afe0611290743p1ebfac17yc2d6b4101e1d8e46@mail.gmail.com> <78d462040611290807m1aada98bv2d420ce7f61b6c7b@mail.gmail.com> <78d462040611300450i312adddcw976f43b8f1680705@mail.gmail.com> Message-ID: <57c63afe0611300519y568435d7n8a7023abb44a6f40@mail.gmail.com> On 11/30/06, Steve Tooke wrote: > Could this be because I'm isolating the controllers from the views, so > nothing is actually being rendered - hence why render is returning > nil? Could be. I haven't had a look at this yet, but that sounds plausible. > > On 11/29/06, Steve Tooke wrote: > > Submitted as Bugs item #6959 > > > > I'm trying to have a crack at fixing this, but I'm not sure exactly > > where I should be looking, I'm guessing its in the controller context? > > > > Cheers, > > Steve > > > > On 11/29/06, David Chelimsky wrote: > > > Would you please submit this directly to the tracker? > > > > > > http://rubyforge.org/tracker/?group_id=797 > > > > > > Thanks, > > > David > > > > > > On 11/29/06, Steve Tooke wrote: > > > > Sorry for the duplicate, I managed to send the incomplete email by accident! > > > > > > > > I think I've come across a small bug which causes the "do and return" > > > > pattern to fail with render or redirect_to inside an controller > > > > action. > > > > > > > > According to changeset 462 (http://dev.rubyonrails.org/changeset/462) > > > > render and redirect_to should both return true, this does not appear > > > > to happen when running specs > > > > > > > > e.g. > > > > > > > > class MyController < ApplicationController > > > > > > > > def index > > > > @page = Page.find(:first, :condtions => ['name = ?', params[:name]]) > > > > show_404 and return unless @page > > > > render :action => :page > > > > end > > > > > > > > protected > > > > def show_404 > > > > render( :file => "#{RAILS_ROOT}/public/404.html", > > > > :status => "404 Not Found") > > > > end > > > > end > > > > > > > > ---------------- > > > > > > > > context "a GET to index with an unrecognised page" do > > > > controller_name :my_controller > > > > > > > > setup do > > > > Page.stub!(:find) > > > > end > > > > > > > > specify "should not assign a page" do > > > > get 'index', :name => 'broken' > > > > assigns['page'].should == nil > > > > end > > > > > > > > specify "should render 404 file" do > > > > controller.should_render :file => "#{RAILS_ROOT}/public/404.html", > > > > :status => "404 Not Found" > > > > get 'index', :name => 'broken' > > > > end > > > > end > > > > > > > > ------------- > > > > > > > > Both of these specs will fail with an > > > > "ActionController::DoubleRenderError", demonstrating that the return > > > > call is being ignored. > > > > > > > > Regards, > > > > Steve > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From mike at vincent.ws Thu Nov 30 08:49:34 2006 From: mike at vincent.ws (Mike Vincent) Date: Thu, 30 Nov 2006 07:49:34 -0600 Subject: [rspec-devel] Updated HTML formatter template In-Reply-To: <57c63afe0611300517q1f8e9902ib1aa949f32953fdf@mail.gmail.com> References: <8d961d900611300458v10fa9d76g58cc414970d2a105@mail.gmail.com> <57c63afe0611300517q1f8e9902ib1aa949f32953fdf@mail.gmail.com> Message-ID: <2386bfa00611300549g61a5ac4j2e17ec21912d8fd3@mail.gmail.com> I was thinking yesterday that something that might be neat is to take one of the various schema visualization tools/plugins out there [1] and alter it to instead of displaying the model or controller details within the bubbles or boxes it displays specdoc output, maybe color the containers red/green as well. [1] http://blog.zmok.net/articles/2006/11/13/visualize-your-rails-schema [1] http://rav.rubyforge.org/ [1] http://visualizemodels.rubyforge.org/ -Mike On 11/30/06, David Chelimsky wrote: > On 11/30/06, aslak hellesoy wrote: > > On 11/30/06, Luke Redpath wrote: > > > I've done a bit of work on the current RSpec HTML formatter template > > > - I've changed the stylesheet and played around with the markup a bit > > > to make it a bit more semantic (I've opted for definition lists for > > > the specs). You can view it here: > > > > > > http://uploads.lukeredpath.co.uk/rspec.html > > > > > > > Looks great in general but... > > > > > It still needs a bit of tweaking, but if nobody has any objections, > > > I'll roll this into the trunk. > > > > > > > people generally associate red with failure and green with success (at > > least in the software testing domain). Aren't these colours at odds > > with the common conventions? My initial reaction was "This is all > > failures". > > > > Agreed. The feel is very nice but the red does imply failure. > > Also - I think that w/ hundreds of specs, this page will get quite > long. I'd like to see something with slightly smaller fonts and less > space without sacrificing the nice look. One can wish, right? > > Thanks Luke, > David > > > Can you show us one that has both passing and failing specs? > > > > Cheers, > > Aslak > > > > > Cheers > > > Luke > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From steve.tooke at gmail.com Thu Nov 30 09:17:01 2006 From: steve.tooke at gmail.com (Steve Tooke) Date: Thu, 30 Nov 2006 14:17:01 +0000 Subject: [rspec-devel] Calls to render and redirect in controllers should return true (rspec-on-rails) In-Reply-To: <57c63afe0611300519y568435d7n8a7023abb44a6f40@mail.gmail.com> References: <78d462040611290735y64370032k7c438fefdbe232bb@mail.gmail.com> <57c63afe0611290743p1ebfac17yc2d6b4101e1d8e46@mail.gmail.com> <78d462040611290807m1aada98bv2d420ce7f61b6c7b@mail.gmail.com> <78d462040611300450i312adddcw976f43b8f1680705@mail.gmail.com> <57c63afe0611300519y568435d7n8a7023abb44a6f40@mail.gmail.com> Message-ID: <78d462040611300617v48a4c9ccw6674485292bc9a35@mail.gmail.com> in Spec::Rails::ControllerInstanceMethods we have this method: def render(options=nil, deprecated_status=nil, &block) unless block_given? unless integrate_views? @template = Spec::Mocks::Mock.new("mock template") @template.stub!(:evaluate_assigns) @template.stub!(:render) @template.stub!(:file_exists?).and_return(true) @template.stub!(:full_template_path) @template.stub!(:render_file) @template.stub!(:render_partial) end end render_matcher.set_actual(ensure_default_options(options), response, &block) super end This seems to sub the render methods, and not return anything, by changing the :render_file stub to return true it solves my problem... the real ActionController::Base#rende_file returns the response body, so I'm not sure that simply setting this to return true is ideal? Steve On 11/30/06, David Chelimsky wrote: > On 11/30/06, Steve Tooke wrote: > > Could this be because I'm isolating the controllers from the views, so > > nothing is actually being rendered - hence why render is returning > > nil? > > Could be. I haven't had a look at this yet, but that sounds plausible. > > > > > On 11/29/06, Steve Tooke wrote: > > > Submitted as Bugs item #6959 > > > > > > I'm trying to have a crack at fixing this, but I'm not sure exactly > > > where I should be looking, I'm guessing its in the controller context? > > > > > > Cheers, > > > Steve > > > > > > On 11/29/06, David Chelimsky wrote: > > > > Would you please submit this directly to the tracker? > > > > > > > > http://rubyforge.org/tracker/?group_id=797 > > > > > > > > Thanks, > > > > David > > > > > > > > On 11/29/06, Steve Tooke wrote: > > > > > Sorry for the duplicate, I managed to send the incomplete email by accident! > > > > > > > > > > I think I've come across a small bug which causes the "do and return" > > > > > pattern to fail with render or redirect_to inside an controller > > > > > action. > > > > > > > > > > According to changeset 462 (http://dev.rubyonrails.org/changeset/462) > > > > > render and redirect_to should both return true, this does not appear > > > > > to happen when running specs > > > > > > > > > > e.g. > > > > > > > > > > class MyController < ApplicationController > > > > > > > > > > def index > > > > > @page = Page.find(:first, :condtions => ['name = ?', params[:name]]) > > > > > show_404 and return unless @page > > > > > render :action => :page > > > > > end > > > > > > > > > > protected > > > > > def show_404 > > > > > render( :file => "#{RAILS_ROOT}/public/404.html", > > > > > :status => "404 Not Found") > > > > > end > > > > > end > > > > > > > > > > ---------------- > > > > > > > > > > context "a GET to index with an unrecognised page" do > > > > > controller_name :my_controller > > > > > > > > > > setup do > > > > > Page.stub!(:find) > > > > > end > > > > > > > > > > specify "should not assign a page" do > > > > > get 'index', :name => 'broken' > > > > > assigns['page'].should == nil > > > > > end > > > > > > > > > > specify "should render 404 file" do > > > > > controller.should_render :file => "#{RAILS_ROOT}/public/404.html", > > > > > :status => "404 Not Found" > > > > > get 'index', :name => 'broken' > > > > > end > > > > > end > > > > > > > > > > ------------- > > > > > > > > > > Both of these specs will fail with an > > > > > "ActionController::DoubleRenderError", demonstrating that the return > > > > > call is being ignored. > > > > > > > > > > Regards, > > > > > Steve > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From contact at lukeredpath.co.uk Thu Nov 30 10:22:31 2006 From: contact at lukeredpath.co.uk (Luke Redpath) Date: Thu, 30 Nov 2006 15:22:31 +0000 Subject: [rspec-devel] Updated HTML formatter template In-Reply-To: <57c63afe0611300517q1f8e9902ib1aa949f32953fdf@mail.gmail.com> References: <8d961d900611300458v10fa9d76g58cc414970d2a105@mail.gmail.com> <57c63afe0611300517q1f8e9902ib1aa949f32953fdf@mail.gmail.com> Message-ID: You're right guys I didn't think of this. Here's a tweaked design, with failures and a successful run: http://uploads.lukeredpath.co.uk/rspec_success.htm http://uploads.lukeredpath.co.uk/rspec_failed.htm Cheers Luke On 30 Nov 2006, at 13:17, David Chelimsky wrote: > On 11/30/06, aslak hellesoy wrote: >> On 11/30/06, Luke Redpath wrote: >>> I've done a bit of work on the current RSpec HTML formatter template >>> - I've changed the stylesheet and played around with the markup a >>> bit >>> to make it a bit more semantic (I've opted for definition lists for >>> the specs). You can view it here: >>> >>> http://uploads.lukeredpath.co.uk/rspec.html >>> >> >> Looks great in general but... >> >>> It still needs a bit of tweaking, but if nobody has any objections, >>> I'll roll this into the trunk. >>> >> >> people generally associate red with failure and green with success >> (at >> least in the software testing domain). Aren't these colours at odds >> with the common conventions? My initial reaction was "This is all >> failures". >> > > Agreed. The feel is very nice but the red does imply failure. > > Also - I think that w/ hundreds of specs, this page will get quite > long. I'd like to see something with slightly smaller fonts and less > space without sacrificing the nice look. One can wish, right? > > Thanks Luke, > David > >> Can you show us one that has both passing and failing specs? >> >> Cheers, >> Aslak >> >>> Cheers >>> Luke >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Thu Nov 30 10:53:24 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 30 Nov 2006 09:53:24 -0600 Subject: [rspec-devel] Updated HTML formatter template In-Reply-To: References: <8d961d900611300458v10fa9d76g58cc414970d2a105@mail.gmail.com> <57c63afe0611300517q1f8e9902ib1aa949f32953fdf@mail.gmail.com> Message-ID: <57c63afe0611300753qeb05404pdcd62de19c11dcca@mail.gmail.com> THAT is sweet! On 11/30/06, Luke Redpath wrote: > You're right guys I didn't think of this. > > Here's a tweaked design, with failures and a successful run: > > http://uploads.lukeredpath.co.uk/rspec_success.htm > http://uploads.lukeredpath.co.uk/rspec_failed.htm > > Cheers > Luke > > On 30 Nov 2006, at 13:17, David Chelimsky wrote: > > > On 11/30/06, aslak hellesoy wrote: > >> On 11/30/06, Luke Redpath wrote: > >>> I've done a bit of work on the current RSpec HTML formatter template > >>> - I've changed the stylesheet and played around with the markup a > >>> bit > >>> to make it a bit more semantic (I've opted for definition lists for > >>> the specs). You can view it here: > >>> > >>> http://uploads.lukeredpath.co.uk/rspec.html > >>> > >> > >> Looks great in general but... > >> > >>> It still needs a bit of tweaking, but if nobody has any objections, > >>> I'll roll this into the trunk. > >>> > >> > >> people generally associate red with failure and green with success > >> (at > >> least in the software testing domain). Aren't these colours at odds > >> with the common conventions? My initial reaction was "This is all > >> failures". > >> > > > > Agreed. The feel is very nice but the red does imply failure. > > > > Also - I think that w/ hundreds of specs, this page will get quite > > long. I'd like to see something with slightly smaller fonts and less > > space without sacrificing the nice look. One can wish, right? > > > > Thanks Luke, > > David > > > >> Can you show us one that has both passing and failing specs? > >> > >> Cheers, > >> Aslak > >> > >>> Cheers > >>> Luke > >>> _______________________________________________ > >>> rspec-devel mailing list > >>> rspec-devel at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/rspec-devel > >>> > >> _______________________________________________ > >> rspec-devel mailing list > >> rspec-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-devel > >> > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From chad at spicycode.com Thu Nov 30 11:31:38 2006 From: chad at spicycode.com (Chad Humphries) Date: Thu, 30 Nov 2006 11:31:38 -0500 Subject: [rspec-devel] Updated HTML formatter template In-Reply-To: <57c63afe0611300753qeb05404pdcd62de19c11dcca@mail.gmail.com> References: <8d961d900611300458v10fa9d76g58cc414970d2a105@mail.gmail.com> <57c63afe0611300517q1f8e9902ib1aa949f32953fdf@mail.gmail.com> <57c63afe0611300753qeb05404pdcd62de19c11dcca@mail.gmail.com> Message-ID: <78155E51-66A1-4EB2-B090-3C1C37E47578@spicycode.com> Here here! I second how awesome this is! -Chad On Nov 30, 2006, at 10:53 AM, David Chelimsky wrote: > THAT is sweet! > > On 11/30/06, Luke Redpath wrote: >> You're right guys I didn't think of this. >> >> Here's a tweaked design, with failures and a successful run: >> >> http://uploads.lukeredpath.co.uk/rspec_success.htm >> http://uploads.lukeredpath.co.uk/rspec_failed.htm >> >> Cheers >> Luke >> >> On 30 Nov 2006, at 13:17, David Chelimsky wrote: >> >>> On 11/30/06, aslak hellesoy wrote: >>>> On 11/30/06, Luke Redpath wrote: >>>>> I've done a bit of work on the current RSpec HTML formatter >>>>> template >>>>> - I've changed the stylesheet and played around with the markup a >>>>> bit >>>>> to make it a bit more semantic (I've opted for definition lists >>>>> for >>>>> the specs). You can view it here: >>>>> >>>>> http://uploads.lukeredpath.co.uk/rspec.html >>>>> >>>> >>>> Looks great in general but... >>>> >>>>> It still needs a bit of tweaking, but if nobody has any >>>>> objections, >>>>> I'll roll this into the trunk. >>>>> >>>> >>>> people generally associate red with failure and green with success >>>> (at >>>> least in the software testing domain). Aren't these colours at odds >>>> with the common conventions? My initial reaction was "This is all >>>> failures". >>>> >>> >>> Agreed. The feel is very nice but the red does imply failure. >>> >>> Also - I think that w/ hundreds of specs, this page will get quite >>> long. I'd like to see something with slightly smaller fonts and less >>> space without sacrificing the nice look. One can wish, right? >>> >>> Thanks Luke, >>> David >>> >>>> Can you show us one that has both passing and failing specs? >>>> >>>> Cheers, >>>> Aslak >>>> >>>>> Cheers >>>>> Luke >>>>> _______________________________________________ >>>>> rspec-devel mailing list >>>>> rspec-devel at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>>>> >>>> _______________________________________________ >>>> rspec-devel mailing list >>>> rspec-devel at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>>> >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From aslak.hellesoy at gmail.com Thu Nov 30 12:36:38 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 30 Nov 2006 18:36:38 +0100 Subject: [rspec-devel] Updated HTML formatter template In-Reply-To: References: <8d961d900611300458v10fa9d76g58cc414970d2a105@mail.gmail.com> <57c63afe0611300517q1f8e9902ib1aa949f32953fdf@mail.gmail.com> Message-ID: <8d961d900611300936o71b4f5b4va871751e2d058dcb@mail.gmail.com> On 11/30/06, Luke Redpath wrote: > You're right guys I didn't think of this. > > Here's a tweaked design, with failures and a successful run: > > http://uploads.lukeredpath.co.uk/rspec_success.htm > http://uploads.lukeredpath.co.uk/rspec_failed.htm > Very nice indeed. Commit commit! > Cheers > Luke > > On 30 Nov 2006, at 13:17, David Chelimsky wrote: > > > On 11/30/06, aslak hellesoy wrote: > >> On 11/30/06, Luke Redpath wrote: > >>> I've done a bit of work on the current RSpec HTML formatter template > >>> - I've changed the stylesheet and played around with the markup a > >>> bit > >>> to make it a bit more semantic (I've opted for definition lists for > >>> the specs). You can view it here: > >>> > >>> http://uploads.lukeredpath.co.uk/rspec.html > >>> > >> > >> Looks great in general but... > >> > >>> It still needs a bit of tweaking, but if nobody has any objections, > >>> I'll roll this into the trunk. > >>> > >> > >> people generally associate red with failure and green with success > >> (at > >> least in the software testing domain). Aren't these colours at odds > >> with the common conventions? My initial reaction was "This is all > >> failures". > >> > > > > Agreed. The feel is very nice but the red does imply failure. > > > > Also - I think that w/ hundreds of specs, this page will get quite > > long. I'd like to see something with slightly smaller fonts and less > > space without sacrificing the nice look. One can wish, right? > > > > Thanks Luke, > > David > > > >> Can you show us one that has both passing and failing specs? > >> > >> Cheers, > >> Aslak > >> > >>> Cheers > >>> Luke > >>> _______________________________________________ > >>> rspec-devel mailing list > >>> rspec-devel at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/rspec-devel > >>> > >> _______________________________________________ > >> rspec-devel mailing list > >> rspec-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-devel > >> > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Thu Nov 30 18:41:46 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 18:41:46 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6980 ] Can't set expectations on Rails association proxy object Message-ID: <20061130234146.6DF905241985@rubyforge.org> Bugs item #6980, was opened at 2006-11-30 05:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6980&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can't set expectations on Rails association proxy object Initial Comment: edge rails, 0.7.3 context "Given a call to destroy, a Person" do setup do @person = Person.create :name => "Me", :user_id => 1 @person.add_item Item.new(:name => "Item") end specify "should destroy its items" do @person.items.should_receive(:delete_all) @person.destroy end end This assumes the following config in Person.rb has_many :items, :dependent => :delete_all The failure is: NoMethodError in 'Given a call to destroy, a Person should destroy its items' undefined method `receive?' for Item:Class My best guess is that since items is a proxy class defined at runtime, the should_receive method isn't getting mixed into it. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 23:41 Message: Have you tried this against 1.1.6? Just curious. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6980&group_id=797 From noreply at rubyforge.org Thu Nov 30 20:40:41 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 20:40:41 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6959 ] Calls to render and redirect in controllers should return true Message-ID: <20061201014041.B86235241996@rubyforge.org> Bugs item #6959, was opened at 2006-11-29 15:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6959&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Steve Tooke (stevetooke) >Assigned to: David Chelimsky (dchelimsky) Summary: Calls to render and redirect in controllers should return true Initial Comment: I think I've come across a small bug which causes the "do and return" pattern to fail with render or redirect_to inside an controller action. According to changeset 462 (http://dev.rubyonrails.org/changeset/462) render and redirect_to should both return true, this does not appear to happen when running specs e.g. class PersonController < ApplicationController def show @person = Person.find(params[:id]) show_404 and return unless @person render :template => 'person/show' end protected def show_404 render( :file => "#{RAILS_ROOT}/public/404.html", :status => "404 Not Found" ) end end ------ context "attempt to show a person that doesn't exist" do controller_name :person setup do Person.stub!(:find) end specify "should not assign a person" do get 'show', :id => 'broken' assigns[:person].should == nil end specify "should render 404 file" do controller.should_render :file => "#{RAILS_ROOT}/public/404.html", :status => "404 Not Found" get 'show', :id => 'broken' end end Both of these specs will fail with an "ActionController::DoubleRenderError", demonstrating that the return call is being ignored, and that render is not returning true. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 01:40 Message: Fixed in trunk (rev 1183). Thank you Steve for contributing the above specs and the solution (solution on the rspec-devel list). Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6959&group_id=797 From noreply at rubyforge.org Thu Nov 30 20:41:05 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 20:41:05 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6959 ] Calls to render and redirect in controllers should return true Message-ID: <20061201014106.166325241996@rubyforge.org> Bugs item #6959, was opened at 2006-11-29 15:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6959&group_id=797 Category: rails plugin Group: None Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Steve Tooke (stevetooke) Assigned to: David Chelimsky (dchelimsky) Summary: Calls to render and redirect in controllers should return true Initial Comment: I think I've come across a small bug which causes the "do and return" pattern to fail with render or redirect_to inside an controller action. According to changeset 462 (http://dev.rubyonrails.org/changeset/462) render and redirect_to should both return true, this does not appear to happen when running specs e.g. class PersonController < ApplicationController def show @person = Person.find(params[:id]) show_404 and return unless @person render :template => 'person/show' end protected def show_404 render( :file => "#{RAILS_ROOT}/public/404.html", :status => "404 Not Found" ) end end ------ context "attempt to show a person that doesn't exist" do controller_name :person setup do Person.stub!(:find) end specify "should not assign a person" do get 'show', :id => 'broken' assigns[:person].should == nil end specify "should render 404 file" do controller.should_render :file => "#{RAILS_ROOT}/public/404.html", :status => "404 Not Found" get 'show', :id => 'broken' end end Both of these specs will fail with an "ActionController::DoubleRenderError", demonstrating that the return call is being ignored, and that render is not returning true. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 01:40 Message: Fixed in trunk (rev 1183). Thank you Steve for contributing the above specs and the solution (solution on the rspec-devel list). Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6959&group_id=797 From noreply at rubyforge.org Thu Nov 30 21:43:38 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 21:43:38 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6980 ] Can't set expectations on Rails association proxy object Message-ID: <20061201024339.08E1652419C0@rubyforge.org> Feature Requests item #6980, was opened at 2006-11-30 05:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 Category: None Group: None Status: Open >Priority: 1 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can't set expectations on Rails association proxy object Initial Comment: edge rails, 0.7.3 context "Given a call to destroy, a Person" do setup do @person = Person.create :name => "Me", :user_id => 1 @person.add_item Item.new(:name => "Item") end specify "should destroy its items" do @person.items.should_receive(:delete_all) @person.destroy end end This assumes the following config in Person.rb has_many :items, :dependent => :delete_all The failure is: NoMethodError in 'Given a call to destroy, a Person should destroy its items' undefined method `receive?' for Item:Class My best guess is that since items is a proxy class defined at runtime, the should_receive method isn't getting mixed into it. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 02:43 Message: Ugh! In activerecord/lib/active_record/associations/association_proxy.rb: class AssociationProxy #:nodoc: attr_reader :reflection alias_method :proxy_respond_to?, :respond_to? alias_method :proxy_extend, :extend instance_methods.each { |m| undef_method m unless m =~ /(^__|^nil\?|^proxy_respond_to\?|^proxy_extend|^send)/ } That last line removes all of the rspec methods. Even if I add ^should_ to the list of methods NOT to undef, I get an error saying that items won't respond_to :delete_all. So Rails is doing a bunch of magic to get things to behave in a way that is somewhat different from how they LOOK like they behave. I'd recommend checking the collection size before and after using should_change for now: lambda { @person.destroy }.should_change(Item, :count).by(-1) It is state-based, but at least you can DO it, and I'd rather focus our energies on getting the rails plugin to do things you can not do at all for the time being. David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 23:41 Message: Have you tried this against 1.1.6? Just curious. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 From noreply at rubyforge.org Thu Nov 30 21:44:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 21:44:12 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6980 ] Can't set expectations on Rails association proxy object Message-ID: <20061201024413.2F90152419C1@rubyforge.org> Feature Requests item #6980, was opened at 2006-11-30 05:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 >Category: rails plugin Group: None Status: Open Priority: 1 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can't set expectations on Rails association proxy object Initial Comment: edge rails, 0.7.3 context "Given a call to destroy, a Person" do setup do @person = Person.create :name => "Me", :user_id => 1 @person.add_item Item.new(:name => "Item") end specify "should destroy its items" do @person.items.should_receive(:delete_all) @person.destroy end end This assumes the following config in Person.rb has_many :items, :dependent => :delete_all The failure is: NoMethodError in 'Given a call to destroy, a Person should destroy its items' undefined method `receive?' for Item:Class My best guess is that since items is a proxy class defined at runtime, the should_receive method isn't getting mixed into it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 02:43 Message: Ugh! In activerecord/lib/active_record/associations/association_proxy.rb: class AssociationProxy #:nodoc: attr_reader :reflection alias_method :proxy_respond_to?, :respond_to? alias_method :proxy_extend, :extend instance_methods.each { |m| undef_method m unless m =~ /(^__|^nil\?|^proxy_respond_to\?|^proxy_extend|^send)/ } That last line removes all of the rspec methods. Even if I add ^should_ to the list of methods NOT to undef, I get an error saying that items won't respond_to :delete_all. So Rails is doing a bunch of magic to get things to behave in a way that is somewhat different from how they LOOK like they behave. I'd recommend checking the collection size before and after using should_change for now: lambda { @person.destroy }.should_change(Item, :count).by(-1) It is state-based, but at least you can DO it, and I'd rather focus our energies on getting the rails plugin to do things you can not do at all for the time being. David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 23:41 Message: Have you tried this against 1.1.6? Just curious. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 From noreply at rubyforge.org Thu Nov 30 22:03:49 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 22:03:49 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6971 ] and_yield does not work when the arity is -1 Message-ID: <20061201030351.5CA7452419D5@rubyforge.org> Bugs item #6971, was opened at 2006-11-29 23:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6971&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: and_yield does not work when the arity is -1 Initial Comment: def foo(bar) bar.call {|*args|} end bar = mock("bar) bar.should_receive(:call).and_yield foo(bar) # Mock 'bar' yielded || to block with arity of -1 ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 03:03 Message: As I understand it, this is the correct behavior: irb(main):021:0> proc {}.arity => -1 irb(main):022:0> proc {||}.arity => 0 irb(main):023:0> proc {|arg|}.arity => 1 irb(main):024:0> proc {|*args|}.arity => -1 In your example, you are yielding 0 orgs to a proc with an arity of -1. Am I missing something? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6971&group_id=797 From noreply at rubyforge.org Thu Nov 30 22:28:51 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 22:28:51 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6980 ] Can't set expectations on Rails association proxy object Message-ID: <20061201032851.3F74E5241994@rubyforge.org> Feature Requests item #6980, was opened at 2006-11-30 00:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 Category: rails plugin Group: None Status: Open Priority: 1 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can't set expectations on Rails association proxy object Initial Comment: edge rails, 0.7.3 context "Given a call to destroy, a Person" do setup do @person = Person.create :name => "Me", :user_id => 1 @person.add_item Item.new(:name => "Item") end specify "should destroy its items" do @person.items.should_receive(:delete_all) @person.destroy end end This assumes the following config in Person.rb has_many :items, :dependent => :delete_all The failure is: NoMethodError in 'Given a call to destroy, a Person should destroy its items' undefined method `receive?' for Item:Class My best guess is that since items is a proxy class defined at runtime, the should_receive method isn't getting mixed into it. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-11-30 22:28 Message: "add_underscores_for_rspec!" gets called on the association base class after that code is parsed, though, and overrides it. That shouldn't be the problem. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 21:43 Message: Ugh! In activerecord/lib/active_record/associations/association_proxy.rb: class AssociationProxy #:nodoc: attr_reader :reflection alias_method :proxy_respond_to?, :respond_to? alias_method :proxy_extend, :extend instance_methods.each { |m| undef_method m unless m =~ /(^__|^nil\?|^proxy_respond_to\?|^proxy_extend|^send)/ } That last line removes all of the rspec methods. Even if I add ^should_ to the list of methods NOT to undef, I get an error saying that items won't respond_to :delete_all. So Rails is doing a bunch of magic to get things to behave in a way that is somewhat different from how they LOOK like they behave. I'd recommend checking the collection size before and after using should_change for now: lambda { @person.destroy }.should_change(Item, :count).by(-1) It is state-based, but at least you can DO it, and I'd rather focus our energies on getting the rails plugin to do things you can not do at all for the time being. David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 18:41 Message: Have you tried this against 1.1.6? Just curious. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 From noreply at rubyforge.org Thu Nov 30 22:58:56 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 30 Nov 2006 22:58:56 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6980 ] Can't set expectations on Rails association proxy object Message-ID: <20061201035856.77D8C5241994@rubyforge.org> Feature Requests item #6980, was opened at 2006-11-30 05:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797 Category: rails plugin Group: None Status: Open Priority: 1 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Can't set expectations on Rails association proxy object Initial Comment: edge rails, 0.7.3 context "Given a call to destroy, a Person" do setup do @person = Person.create :name => "Me", :user_id => 1 @person.add_item Item.new(:name => "Item") end specify "should destroy its items" do @person.items.should_receive(:delete_all) @person.destroy end end This assumes the following config in Person.rb has_many :items, :dependent => :delete_all The failure is: NoMethodError in 'Given a call to destroy, a Person should destroy its items' undefined method `receive?' for Item:Class My best guess is that since items is a proxy class defined at runtime, the should_receive method isn't getting mixed into it. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 03:58 Message: handle_underscores_for_rspec! doesn't reinstate the should methods - it reinstates the underscore sugar that gets invoked on method_missing. Right now, that is only still in existence to support should_be_predicate, but that is on its way out soon. I added the following to puts ActiveRecord::Associations::HasManyAssociation.included_modules.inspect ActiveRecord::Associations::HasManyAssociation.send :include, Spec::Mocks::MockMethods puts ActiveRecord::Associations::HasManyAssociation.included_modules.inspect Here's what it output: [Base64::Deprecated, Base64, Spec::Mocks::MockMethods, Spec::Expectations::UnderscoreSugar, Spec::Expectations::ObjectExpectations, Callback::InstanceMethods, Kernel] [Base64::Deprecated, Base64, Spec::Mocks::MockMethods, Spec::Expectations::UnderscoreSugar, Spec::Expectations::ObjectExpectations, Callback::InstanceMethods, Kernel] Note that Spec::Mock::MockMethods appears before and after. So there's something happening at runtime. ---------------------------------------------------------------------- Comment By: Wilson Bilkovich (wilson) Date: 2006-12-01 03:28 Message: "add_underscores_for_rspec!" gets called on the association base class after that code is parsed, though, and overrides it. That shouldn't be the problem. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-12-01 02:43 Message: Ugh! In activerecord/lib/active_record/associations/association_proxy.rb: class AssociationProxy #:nodoc: attr_reader :reflection alias_method :proxy_respond_to?, :respond_to? alias_method :proxy_extend, :extend instance_methods.each { |m| undef_method m unless m =~ /(^__|^nil\?|^proxy_respond_to\?|^proxy_extend|^send)/ } That last line removes all of the rspec methods. Even if I add ^should_ to the list of methods NOT to undef, I get an error saying that items won't respond_to :delete_all. So Rails is doing a bunch of magic to get things to behave in a way that is somewhat different from how they LOOK like they behave. I'd recommend checking the collection size before and after using should_change for now: lambda { @person.destroy }.should_change(Item, :count).by(-1) It is state-based, but at least you can DO it, and I'd rather focus our energies on getting the rails plugin to do things you can not do at all for the time being. David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-30 23:41 Message: Have you tried this against 1.1.6? Just curious. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6980&group_id=797