I ran into a recent problem writing specs for a helper. I was testing
a helper that uses the standard memoization technique of caching the
result of an expensive calculation in an instance variable:
def something_expensive
@something_expensive ||= do_something_expensive
end
I have
Thanks, David. I searched the google group for discussions of my
problem but forgot to search the github issues. I'll be sure to check
there next time!
On Feb 8, 5:17 pm, David Chelimsky dchelim...@gmail.com wrote:
On Mon, Feb 8, 2010 at 1:44 PM, Myron Marston myron.mars...@gmail.com wrote
On my current rails project we're using both rspec and cucumber.
We've been diligent about keeping our specs as true unit tests, using
nulldb and mocking/stubbing to disconnect the specs from the database
and keep each spec focused on the class/method under test. Our
cucumber features are
googling but haven't found anything yet).
Myron
On May 19, 2:19 pm, David Chelimsky dchelim...@gmail.com wrote:
On May 19, 2010, at 4:11 PM, Myron Marston wrote:
On my current rails project we're using both rspec and cucumber.
We've been diligent about keeping our specs as true unit tests, using
You can still get the same outcome, but you have to implement it in the group
like this:
unless defined?(:foo)
def foo; foo; end
end
Good point--I hadn't thought of that. The one issue I see with it is
that the author of the shared example group may not have knowledge of
which helper
The particular issue of simple values being used in the docstrings and the
examples themselves (i.e. exposed to everything in the block scope) could be
handled like this:
shared_examples_for blah do |a,b|
...
end
it_should_behave_like blah, 1, 2
Fantastic idea. I'm sold. I'm not
Seems like your mental model is that of a customization block being a
subclass or re-opening of the shared block. What you say makes sense in that
model, but that's not the same model I have.
My mental model is indeed that the customization block is like a
subclass. I'm not sure where I got
If we do this, we should use module_exec for both blocks so they both get the
same arguments.
I actually find the use of this to be a bit confusing:
[:foo, :bar].each do |arg|
it_should_behave_like Something, arg do |a|
# The value of the param is already bound to arg and now it's
bound
OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I
came up with:
http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e
It works (at least in the sense that it allows the specs and features
I added in the previous commits in that branch to
This may be useful for folks migrating...
I recently updated one of my projects to RSpec 2. Here's the commit
with all the changes:
http://github.com/myronmarston/vcr/commit/f05cc59abc16b711e345bab2994ad2ebfdce7170
Summary:
- Updated rakefile so it defines new spec tasks
- Migrated
Ashley: thanks for posting the example. It's nice to see how this all
fits together.
Re: RSpec 2 for ruby 1.8.6: I don't see RSpec 2 as being all that
useful for Rails 2.x projects on ruby 1.8.6. However, it's still very
important for gems. I just converted one of my projects (VCR[1]) to
RSpec
I wouldn't even bother to undef those methods.
If we don't undef the methods, then the semantics of the
#module_eval_with_args (or whatever we call it) will be different on
1.8.6 and other versions. On 1.8.6, a method definition in the block
would define both an instance method _and_ a class
The before block and the macro declaration get run in different
contexts. In the before block, self is an instance of the example
group. Your macro declaration runs with self set to the example group
itself.
It's the difference between an instance variable of a Class instance
(since Classes are
Good error messages are important to a library's usability. Could we
find away to give the user a good error message when they override a
reserved method?
I'm thinking this could be accomplished with 2 simple pieces:
1. A method_added hook in Rspec-core that gives a warning or error
when a
Sorry it's taken me so long to respond--I have considerably less time
on weekdays than the weekend to take care of things like this.
Yehuda Katz made a similar suggestion to me, referencing some code from
merb:http://github.com/merb/merb/blob/master/merb-core/lib/merb-core/contr...
Merb also
I think they should all be registered in the same place, in rspec-core. Or
are you saying that rspec-rails would take the responsibility of registering
the names for rspec-rails, rails, test/unit and minitest? That makes sense to
me, as long as they're all using
I've been refactoring the specs for my VCR gem[1] to take advantage of
the new shared example group parameterization. VCR supports both
FakeWeb and WebMock, with an appropriate adapter class implemented for
each. The adapter classes have nearly identical behavior, except for
the differences in
4 makes sense to me iff the code does actually run correctly in all
circumstances, otherwise I'd lean towards 3.
Given that ruby blocks are just code, and you can do anything you want
in them, and that our faked version of #module_exec runs the block
twice...it's easy to conceive of ways of
1. Find a better way to fake module_exec on ruby 1.8.6. I'm not sure
if this is even doable.
Actually, after thinking about this some more, I think I've come up
with a solution that will eliminate the error I'm seeing, but it's not
a perfect solution. Let me see if I can explain this well...
I messed with this some more and implemented the idea I mentioned
above:
http://github.com/myronmarston/rspec-core/commit/ec3001f290b091fcdab9fb972d9596dd34a91e4e
I think this is *definitely* a better implementation of
#module_eval_with_args for ruby 1.8.6. It does have the undesirable
side
One assertion per test [1] is a good rule of thumb, but don't get too hung up
about it.
To rephrase this slightly, you should test one behavior per spec, and
having multiple assertions or expectations in the same test is a good
sign that you may be testing multiple behaviors.
One of the primary dangers of using mocks is that your unit tests may
be testing against an interface that is different from that of your
production objects. You may simply have misspelled the method (e.g.
object.should_receive(:methd_name) rather than method_name), or you
may have changed the
What defines a concrete object?
Anything that is not an RSpec stub object?
Yep, that's how I'm using the term. It doesn't make sense to do a
respond_to? check on a pure mock or stub object, since it doesn't
initially have a defined interface (outside of the interface of
Object).
My other objection is that we're dealing with a dynamic
language here, and there are going to be cases in which methods
are defined dynamically. For average users, this is likely not
a problem (as long as the check is done at the time the stub is
invoked rather than when the stub is defined)
I think separate from the spec run mislead you as to my intention here.
What I mean is that I don't want this to raise errors, but rather it
would be part of the output, just like pending and failed examples.
I'm OK with this idea. I just didn't want to have a separate file to
read :).
I
On Sep 13, 1:01 am, Justin Ko jko...@gmail.com wrote:
On Sep 13, 3:58 am, nathanvda nathan...@gmail.com wrote:
Whoops. Found it! I have a rcov.rake inside my lib/tasks like this:
desc Run all specs with rcov
RSpec::Core::RakeTask.new(test_cov) do |t|
t.rcov = true
t.rcov_opts
On Sep 17, 12:48 pm, Doug E. d...@emeryit.com wrote:
Hi,
I'm trying to understand BDD and proper testing technique. I'm testing
a rails view helper method that checks user roles to see if a link
should be shown. I'm using rails 2.3.8 and rspec version 1.3.0. My
helper looks like this:
#
On Sep 18, 11:52 am, Doug E. d...@emeryit.com wrote:
On Sep 17, 9:16 pm, Myron Marston myron.mars...@gmail.com wrote:
On Sep 17, 12:48 pm, Doug E. d...@emeryit.com wrote:
Hi,
I'm trying to understand BDD and proper testing technique. I'm testing
a rails view helper method
The current behavior of rspec-mocks causes a NoMethodError when you
call object.foo(x) after setting up a stub using
object.stub(:foo).with(y). Here's an example for when this has caused
me a problem:
- In a before(:each) block, I've setup a stub:
class Cat
class self
def start
id = get_uuid
begin
yield if block_given?
ensure
set_some_other_state
end
end
end
#...
end
In spite of the fact that you have an #id= method, `id = get_uuid` is
You can reorganize it a bit in a way that will work on 1.8.7, 1.9.1
and 1.9.2:
module Foo
module Quux
class Baz
def name
noise
end
end
end
end
describe Foo::Quux::Baz do
it has a name do
described_class.new.name.should == 'noise'
end
end
On Feb 21, 11:45 am, Curtis j Schofield curtis.schofi...@gmail.com
wrote:
Has anyone else encountered this?
It will end up printing this :
1) Applications Scribd api requests should always be private
Failure/Error: Unable to find matching line from backtrace
SystemStackError:
On Mar 11, 1:17 pm, Justin Ko jko...@gmail.com wrote:
On Thu, Mar 10, 2011 at 2:32 AM, Shamaoke shama...@hotmail.com wrote:
Hi.
Why doesn't the following filter work?
~~~
# encoding: utf-8
# ./example_spec.rb
RSpec.configure do |config|
config.filter = {
unless:
I've opened a pull request with an initial implementation of using
`expect` to set normal expectations in addition to block ones:
expect(something).to be_awesome
Note that it's not simply the syntax change that's driving the
possibility of introducing this. It's the fact that the `should` and
RSpec provides an around(:each) hook but no around(:all) hook. I realized
recently that you can build an around hook out of separate before/after
hooks using fibers, and decided to blog about it [1], using an around(:all)
hook as the example. Some of you may find it interesting or even
I've been thinking about this a bit ever since Zach Dennis brought up
the issue on another rspec-expectations ticket [1]. I've come up with
a proof-of-concept matcher that works pretty well, I think [2].
Here's how you use it:
expect { |b| 3.tap(b) }.to yield_value(3)
The argument passed to the
On Friday, November 1, 2013 11:07:24 AM UTC-7, Kylo Ginsberg wrote:
I just discovered that running a specific test or set of tests via
:line doesn't honor filters but --line_number line does. E.g.
cat fun_with_line_numbers.rb
describe :if = false, :if = false do
it should not run do
Use which ever you prefer. One is an alias for the other. In my
experience, I've found that `not_to` reads more naturally sometimes, and
`to_not` reads more naturally sometimes (for purely subjective reasons).
My advice is to use whichever comes out naturally when you are writing
your
38 matches
Mail list logo
