Send rspec-users mailing list submissions to
rspec-users@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
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
Subject: Re: [rspec-users] Associations should be private
To: rspec-users <rspec-users@rubyforge.org>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Oct 1, 2008 at 7:06 PM, David Chelimsky
<[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]>
Subject: [rspec-users] Need to clear Mocha expectation?
To: rspec-users@rubyforge.org
Message-ID: <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
Subject: Re: [rspec-users] Need to clear Mocha expectation?
To: rspec-users@rubyforge.org
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Oct 2, 2008 at 5:20 PM, Peter Degen-Portnoy
<[EMAIL PROTECTED]> 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@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
------------------------------
Message: 4
Date: Fri, 3 Oct 2008 05:43:49 +0200
From: Evan Dorn <[EMAIL PROTECTED]>
Subject: [rspec-users] how to catch a missing image (rspec-rails)
To: rspec-users@rubyforge.org
Message-ID: <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
Subject: [rspec-users] [ANN] RSpec-1.1.7 is released
To: rspec-users <rspec-users@rubyforge.org>, rspec-devel
<[EMAIL PROTECTED]>, "ruby-talk ML" <[EMAIL PROTECTED]
lang.org>
Message-ID:
<[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Subject: Re: [rspec-users] how to catch a missing image (rspec-rails)
To: rspec-users@rubyforge.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Evan Dorn <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
Subject: [rspec-users] [ANN] RSpec-1.1.8
To: rspec-users <rspec-users@rubyforge.org>, rspec-devel
<[EMAIL PROTECTED]>, "ruby-talk ML" <[EMAIL PROTECTED]
lang.org>
Message-ID:
<[EMAIL PROTECTED]>
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@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
End of rspec-users Digest, Vol 28, Issue 9
******************************************
