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
> ******************************************