[rspec-users] Difference between gem and plugin

Donald French dhf0820 at gmail.com
Fri Oct 3 16:46:44 EDT 2008


Can someone tell me the difference ins the gem versions and the plugin  
versions? do they work together? need both?

Don French
On Oct 3, 2008, at 3:14 AM, rspec-users-request at rubyforge.org wrote:

> Send rspec-users mailing list submissions to
> 	rspec-users at rubyforge.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://rubyforge.org/mailman/listinfo/rspec-users
> or, via email, send a message with subject or body 'help' to
> 	rspec-users-request at rubyforge.org
>
> You can reach the person managing the list at
> 	rspec-users-owner at rubyforge.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of rspec-users digest..."
>
>
> Today's Topics:
>
>   1. Re: Associations should be private (Mark Wilden)
>   2. Need to clear Mocha expectation? (Peter Degen-Portnoy)
>   3. Re: Need to clear Mocha expectation? (David Chelimsky)
>   4. how to catch a missing image (rspec-rails) (Evan Dorn)
>   5. [ANN] RSpec-1.1.7 is released (David Chelimsky)
>   6. Re: how to catch a missing image (rspec-rails) (Pat Maddox)
>   7. [ANN] RSpec-1.1.8 (David Chelimsky)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 2 Oct 2008 10:01:47 -0700
> From: "Mark Wilden" <mark at mwilden.com>
> Subject: Re: [rspec-users] Associations should be private
> To: rspec-users <rspec-users at rubyforge.org>
> Message-ID:
> 	<3c30da400810021001l3859606aw39cd74dd704634bb at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wed, Oct 1, 2008 at 7:06 PM, David Chelimsky  
> <dchelimsky at gmail.com>wrote:
>
>>
>> Au contraire! You're comparing apples and cadillacs here. Demeter is
>> about encapsulation. Interfaces are about abstraction and structure.
>> Completely different animals.
>
>
> Interfaces in that Java book and LOD in this topic were being  
> supported by
> arguments of the form "if you need to change things in the  
> future..." There
> are some practitioners for whom that's a valid argument, and there are
> others for whom it's an anti-argument. YAGNI is the latter. Doesn't  
> make it
> right, but it does provide a way to evaluate each of these animals.
>
>
>> Tracking down all of the trainwrecks in a system is not quite so
>> simple. First of all, they are not guaranteed to look the same:
>>
>> trainer.animals.dogs.first
>>
>> vs
>>
>> t = trainer
>> a = trainer.animals
>> d = trainer.dogs
>> dog = dogs[0]
>>
>> So when the design seems to want to categorize animals into domestic
>> and wild, the first call has to be changed to
>> trainer.animals.domestic.dogs.first. Good luck tracking down the
>> second example
>
>
> In a statically-typed language, this would be trivial. In a
> dynamically-typed language using BDD, this would be caught by tests.
>
>
>> Principles/guidelines like YAGNI and DRY and even the
>> ever-threatening-sounding Law of Demeter are NOT LAWS. They are
>> indicators. Red flag triggers. Red flags are *warnings*, not  
>> *errors*.
>>
>
> We agree on that. See my recent post:
> http://www.nabble.com/Prepare-for-newbie-ness- 
> to19516110.html#a19542377
>
> In this case, we've got two of these in direct conflict with each
>
>> other, so which one wins? Gotta look at the costs and benefits of  
>> each
>> and proceed wisely and *in context*
>
>
> I feel that YAGNI and LOD are at different levels of granularity. I  
> use
> YAGNI and TSTTCPW in my daily life (which isn't to say that I always  
> think
> they're the best approach). So I approach problems using those  
> principles as
> my base. I don't ask myself a hundred times a day whether I should  
> use a
> goto statement - I use structured programming as my base. Same with  
> OOP,
> readable code, lack of commenting, etc. You can't approach  
> everything de
> novo. So I apply YAGNI unless I see a compelling reason not to. The  
> reason
> is that the "costs and benefits" of any approach are usually not  
> obvious -
> especially when talking about the future.
>
> ///ark
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081002/b8d66710/attachment-0001.html 
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 3 Oct 2008 00:20:57 +0200
> From: Peter Degen-Portnoy <lists at ruby-forum.com>
> Subject: [rspec-users] Need to clear Mocha expectation?
> To: rspec-users at rubyforge.org
> Message-ID: <16f3627bd0241e78308013039ad35366 at ruby-forum.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi Folks,
>
> I have a problem that I have been able to isolate into a small test
> application.
>
> The problem seems to be that when I set an expectation on the number  
> of
> times a method will be called in one describe block, the expectation  
> is
> still set in a different describe block.  My understanding was that
> RSpec restored the state of objects and the end of a test, which I
> interpreted as the end of a describe block (seeing that the scope of  
> the
> expectation ended).
>
> Here is my test application:
> : rails rspecproblem
> : cd rspecproblem
> <install rspec & rspec-rails>
> : script/generate rspec_model Contest contest_name:string  
> status:integer
> contest_series_id:integer
> : script/generate rspec_model ContestSeries series_name:string
> : rake db:migrate
> : autotest
>
> I edited contest.rb and set the following:
> class Contest < ActiveRecord::Base
>  belongs_to :contest_series
>
>  def getSeries
>    ContestSeries.find(contest_series_id)
>  end
> end
>
> I edited contest_series.rb and added the has_many statement:
> class ContestSeries < ActiveRecord::Base
>  has_many :contests
> end
>
>
> I then created the following spec file in spec/models/contest_spec.rb
> that can be found at http://pastie.org/283936
>
> The summary of the test spec is that there are two describe blocks.   
> The
> first block creates a Contest and assigns it to a ContestSeries.  For
> the sake of the example, I then call ContestSeries.find().
>
> The second block sets an expectation on ContestSeries that the find
> method will be called only once.
>
> This causes the following error:
>
> Mocha::ExpectationError in 'Contest should demonstrate that the stub  
> is
> not cleared'
> unexpected invocation: ContestSeries(id: integer, series_name: string,
> created_at: datetime, updated_at: datetime).find(1)
> satisfied expectations:
> - expected exactly once, already invoked once: ContestSeries(id:
> integer, series_name: string, created_at: datetime, updated_at:
> datetime).find(1000)
>
> Playing around with some variations, I have found that if I change the
> code in line 24 to:
>
> ContestSeries.expects(:find).at_least(1)
>
> then no error is generated, but this isn't really what I want.  I want
> to be confident that the "getSeries" call (which is really only a
> simplification of the actual code) gets the correct ContestSeries.
>
> Have I misunderstood how to use this stubbing behavior?  Is there a  
> way
> to correctly clear such expectations in an after block?
>
> Many thanks,
>
> Peter
> -- 
> Posted via http://www.ruby-forum.com/.
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 2 Oct 2008 17:53:47 -0500
> From: "David Chelimsky" <dchelimsky at gmail.com>
> Subject: Re: [rspec-users] Need to clear Mocha expectation?
> To: rspec-users at rubyforge.org
> Message-ID:
> 	<57c63afe0810021553t3d127451oe3d31cbad8482316 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Oct 2, 2008 at 5:20 PM, Peter Degen-Portnoy
> <lists at ruby-forum.com> wrote:
>> Hi Folks,
>>
>> I have a problem that I have been able to isolate into a small test
>> application.
>>
>> The problem seems to be that when I set an expectation on the  
>> number of
>> times a method will be called in one describe block, the  
>> expectation is
>> still set in a different describe block.  My understanding was that
>> RSpec restored the state of objects and the end of a test, which I
>> interpreted as the end of a describe block (seeing that the scope  
>> of the
>> expectation ended).
>>
>> Here is my test application:
>> : rails rspecproblem
>> : cd rspecproblem
>> <install rspec & rspec-rails>
>> : script/generate rspec_model Contest contest_name:string  
>> status:integer
>> contest_series_id:integer
>> : script/generate rspec_model ContestSeries series_name:string
>> : rake db:migrate
>> : autotest
>>
>> I edited contest.rb and set the following:
>> class Contest < ActiveRecord::Base
>> belongs_to :contest_series
>>
>> def getSeries
>>   ContestSeries.find(contest_series_id)
>> end
>> end
>>
>> I edited contest_series.rb and added the has_many statement:
>> class ContestSeries < ActiveRecord::Base
>> has_many :contests
>> end
>>
>>
>> I then created the following spec file in spec/models/contest_spec.rb
>> that can be found at http://pastie.org/283936
>>
>> The summary of the test spec is that there are two describe  
>> blocks.  The
>> first block creates a Contest and assigns it to a ContestSeries.  For
>> the sake of the example, I then call ContestSeries.find().
>>
>> The second block sets an expectation on ContestSeries that the find
>> method will be called only once.
>>
>> This causes the following error:
>>
>> Mocha::ExpectationError in 'Contest should demonstrate that the  
>> stub is
>> not cleared'
>> unexpected invocation: ContestSeries(id: integer, series_name:  
>> string,
>> created_at: datetime, updated_at: datetime).find(1)
>> satisfied expectations:
>> - expected exactly once, already invoked once: ContestSeries(id:
>> integer, series_name: string, created_at: datetime, updated_at:
>> datetime).find(1000)
>>
>> Playing around with some variations, I have found that if I change  
>> the
>> code in line 24 to:
>>
>> ContestSeries.expects(:find).at_least(1)
>
> You learn something new every day!
>
> First, the fix: in spec_helper.rb
>
> Spec::Runner.configure do |config|
>  ...
>  config.mock_with :mocha
>  ...
> end
>
> The problem is that rspec needs to know that you're using mocha in
> order for it to call the mocha methods needed to verify and reset at
> the end of each example.
>
> The reason that the examples that use mocha methods seem to recognize
> those mocha methods is that, as I only just learned, rails *might*
> automatically load mocha in the test environment (depending on a few
> other factors in your system) implicitly without any direction to do
> so. If you're a mocha user, this is a good thing. Not so great if
> you're using other frameworks :) C'est la vie.
>
> Cheers,
> David
>
>
>
>>
>> then no error is generated, but this isn't really what I want.  I  
>> want
>> to be confident that the "getSeries" call (which is really only a
>> simplification of the actual code) gets the correct ContestSeries.
>>
>> Have I misunderstood how to use this stubbing behavior?  Is there a  
>> way
>> to correctly clear such expectations in an after block?
>>
>> Many thanks,
>>
>> Peter
>> --
>> Posted via http://www.ruby-forum.com/.
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 3 Oct 2008 05:43:49 +0200
> From: Evan Dorn <lists at ruby-forum.com>
> Subject: [rspec-users] how to catch a missing image (rspec-rails)
> To: rspec-users at rubyforge.org
> Message-ID: <18c7e87b177b2209d9ab23beae0b73d5 at ruby-forum.com>
> Content-Type: text/plain; charset=utf-8
>
> I want to make sure all external resources called for by my views  
> (like
> images) actually exist.  How do I write an rspec that will fail when  
> an
> image included on the page isn't present?
>
>
> For example, let's say in application.html.erb, I include <img
> src="/images/mylogo.png">, but that file doesn't exist (say it's
> actually /images/mylogo.jpg).
>
> When this is run on the server, the image won't appear, and the server
> log will show an error like this:
>
>>> ActionController::RoutingError (No route matches
> "/images/mylogo.png" with
>>> {:method=>:get}):
>
> However, views tests like response.should have_tag(img[src=/ 
> mylogo.png/)
> won't catch it, because the tag will be there.    controllers tests
> (with integrate_views on) for response.should be_success,
> render_template won't catch it because the page itself was a success  
> and
> rendered the template.
>
> But an error was thrown during a second connection to the server,
> because the image file didn't exist ... there must be a way for any  
> such
> failures.  How?
>
> Thanks!
> Ev
> -- 
> Posted via http://www.ruby-forum.com/.
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 2 Oct 2008 22:52:51 -0500
> From: "David Chelimsky" <dchelimsky at gmail.com>
> Subject: [rspec-users] [ANN] RSpec-1.1.7 is released
> To: rspec-users <rspec-users at rubyforge.org>, 	rspec-devel
> 	<rspec-devel at rubyforge.org>, 	"ruby-talk ML" <ruby-talk at ruby- 
> lang.org>
> Message-ID:
> 	<57c63afe0810022052k529b84bid56bc50c6417097d at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> The RSpec Development is happy to announce the release of rspec-1.1.7
> and rspec-rails-1.1.7
>
> This is recommended for anyone who upgraded to 1.1.5 earlier this week
> as it addresses bugs that were introduced by that release:
>
> == rspec and rspec-rails 1.1.7
>
> * fixed dependency problem introduced in rspec-rails-1.1.6 earlier
> this evening :(
>
> == rspec-1.1.6
>
> * 2 bug fixes
>
> 	* fixed bug where negative message expectations following stubs
> resulted in false (negative) positives. Fixes #548.
> 	* fixed bug where Not Yet Implemented examples report incorrect
> caller. Fixes #547.
>
> * 1 minor enhancement
>
> 	* removed deprecated mock argument constraint symbols
>
> == rspec-rails-1.1.6
>
> * 1 bug fix
>
> 	* fixed regression where values assigned to the assigns hash were not
> accessible from the example. Fixes #549.
>
> == More Information
>
> http://rspec.info/
> http://github.com/dchelimsky/rspec/wikis
> http://rspec.lighthouseapp.com/
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 02 Oct 2008 22:20:10 -0700
> From: Pat Maddox <pergesu at gmail.com>
> Subject: Re: [rspec-users] how to catch a missing image (rspec-rails)
> To: rspec-users at rubyforge.org
> Message-ID: <m2od22gsqd.fsf at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> Evan Dorn <lists at ruby-forum.com> writes:
>
>> I want to make sure all external resources called for by my views  
>> (like
>> images) actually exist.  How do I write an rspec that will fail  
>> when an
>> image included on the page isn't present?
>>
>>
>> For example, let's say in application.html.erb, I include <img
>> src="/images/mylogo.png">, but that file doesn't exist (say it's
>> actually /images/mylogo.jpg).
>>
>> When this is run on the server, the image won't appear, and the  
>> server
>> log will show an error like this:
>>
>>>> ActionController::RoutingError (No route matches
>> "/images/mylogo.png" with
>>>> {:method=>:get}):
>>
>> However, views tests like response.should have_tag(img[src=/ 
>> mylogo.png/)
>> won't catch it, because the tag will be there.    controllers tests
>> (with integrate_views on) for response.should be_success,
>> render_template won't catch it because the page itself was a  
>> success and
>> rendered the template.
>>
>> But an error was thrown during a second connection to the server,
>> because the image file didn't exist ... there must be a way for any  
>> such
>> failures.  How?
>
> Hi Evan,
>
> Can you rely on the convention that images are under RAILS_ROOT/ 
> public?
> If so, you could do a little translucent-box testing.  Maybe you could
> use hpricot to get all the image elements and check their referenced
> file's existence.
>
> # I'm just BSing the hpricot
> hpricot("doc/img") do |element|
>  element.attr('src').should be_existing_resource
> end
>
> Where be_existing_resource is a custom matcher with a simple
> implementation of
>
> def matches?(actual)
>  File.exists?(File.expand_path(RAILS_ROOT + actual))
> end
>
> (simple enough for a simple matcher, even)
>
> This should give you a good deal of confidence without any hassle.
>
> Pat
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 3 Oct 2008 08:14:22 -0500
> From: "David Chelimsky" <dchelimsky at gmail.com>
> Subject: [rspec-users] [ANN] RSpec-1.1.8
> To: rspec-users <rspec-users at rubyforge.org>, 	rspec-devel
> 	<rspec-devel at rubyforge.org>, 	"ruby-talk ML" <ruby-talk at ruby- 
> lang.org>
> Message-ID:
> 	<57c63afe0810030614u6e245034u51e86ba644630112 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Thanks to some very quick feedback on the 1.1.7 release, the RSpec
> Development Team is proud to announce yet another bug fix release:
> RSpec-1.1.8.
>
> RSpec-1.1.8 includes the following changes:
>
> == rspec-1.1.8
>
> * 2 bug fixes
>
>  * restore colorized output in linux and windows w/ autotest (Tim
> Pope). Fixes #413.
>  * autospec no longer hangs on windows. Fixes #554.
>
> == rspec-rails-1.1.8
>
> * 2 bug fixes
>
>  * correctly handle assigns that are false. Fixes #552.
>  * ensure that NotYetImplemented examples report as pending (fixed in
> rspec, not rspec-rails). Fixes #553.
>
> == Install
>
> [sudo] gem install rspec
> [sudo] gem install rspec-rails
>
> == More information
>
> http://rspec.info
> http://rubyforge.org/projects/rspec/
> http://github.com/dchelimsky/rspec/wikis
> http://rspec.lighthouseapp.com/
>
>
> ------------------------------
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
> End of rspec-users Digest, Vol 28, Issue 9
> ******************************************



More information about the rspec-users mailing list