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 expect
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
> ":" doesn't honor filters but "--line_number " does. E.g.
>
> > cat fun_with_line_numbers.rb
> describe ":if => false", :if => false do
> it "should not ru
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
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
potent
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
`s
On Mar 11, 1:17 pm, Justin Ko wrote:
> On Thu, Mar 10, 2011 at 2:32 AM, Shamaoke wrote:
> > Hi.
>
> > Why doesn't the following filter work?
>
> > ~~~
> > # encoding: utf-8
> > # ./example_spec.rb
>
> > RSpec.configure do |config|
> > config.filter = {
> > unless: :condition_acceptable
> > }
On Feb 21, 11:45 am, Curtis j Schofield
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:
> stack level t
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
__
> 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 =
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:
File.stub(:exist?).with("config.yml").and_return(
On Sep 18, 11:52 am, "Doug E." wrote:
> On Sep 17, 9:16 pm, Myron Marston wrote:
>
>
>
>
>
> > On Sep 17, 12:48 pm, "Doug E." wrote:
>
> > > Hi,
>
> > > I'm trying to understand BDD and proper testing technique. I'
On Sep 17, 12:48 pm, "Doug E." 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:
>
> # welcom
On Sep 13, 1:01 am, Justin Ko wrote:
> On Sep 13, 3:58 am, nathanvda 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 = %w{--rails -
> 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 :).
>
> 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 defin
> 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).
___
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 int
> 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.
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 effe
> 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..
> 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 a
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 th
> 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 RSpec::Core::register_res
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 a
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 res
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
> 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 me
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
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 simple_matc
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 pa
> 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
bo
> 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 g
> 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.
> 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 help
I may be the only one who finds this useful, but I think there's value
in evaluating the customization block after the shared example group
block. It allows the shared example group to provide a default
implementation of a helper method, and then an instance of the shared
behavior to override the
-I've done
some googling but haven't found anything yet).
Myron
On May 19, 2:19 pm, David Chelimsky 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 a
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 integrat
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 wrote:
> On Mon, Feb 8, 2010 at 1:44 PM, Myron Marston wrote:
> > I ran into a recent p
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 severa
39 matches
Mail list logo
