Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

New syntax #266

Merged
merged 22 commits into from

6 participants

@myronmarston
Owner

This is my first pass stab at the new syntax discussed in #153.

It's not ready to merge yet but I wanted to start the code review conversation. Notes:

  • I decided to call the old syntax the :direct syntax because you call methods directly on the object...and the new syntax the :wrapped syntax because you wrap the object with a method like expect or allow. What do others think of these names?
  • When we introduced the new syntax to rspec-expectations, we decided to default to both syntaxes enabled. This was necessary because we had supported expect { }.to for a long time, so it would have been a backwards incompatibility to only enable should by default. This time around, I'm thinking of only enabling the existing :direct syntax by default. Generally, I think projects should pick one syntax or the other, and only use both syntaxes during a transition period. There's no need to enable both syntaxes for backwards compatibility like there was for rspec-expectations. On the other hand, it might encourage more folks to try out the new syntax if both are enabled. I'm kinda on the fence here.
  • For any_instance stubbing, we never figured out what to do for the new syntax. For now, I've gone with expect_any_instance_of(klass).to receive and allow_any_instance_of(klass).to receive but @alindeman put together a gist of some other possibilities to consider.
  • With the current version of this code, the any instance stuff doesn't actually work when you enable only the :wrapped syntax (it works fine when both syntaxes are enabled). The problem is that the way that any instance works, it records should_receive and stub and then plays it back on the instance later...but with the :direct syntax disabled, the methods aren't there to playback onto. I'm not sure of a fix yet.
  • I didn't realize this, but the old syntax allowed any object to be as_null_object. I personally think that only makes sense on a test double, not on a partial mock. Any objections to only supporting it on test doubles for the new syntax? (On a side note, I need to enable it when only the new syntax is enabled).
  • stub_chain: Do we need to bring this forward to the new syntax? (It's kind a code smell, IMO).
  • The old syntax supported obj.stub(:msg_1 => 1, :msg_2 => 2) but I can't think of a good way to support that with the new syntax. (We'll still support double(:msg_1 => 1, :msg_2 => 2), of course). Any objects to not bringing that forward to the new syntax?
  • unstub isn't (yet) supported with the new syntax, and I'm on the fence about whether to support it or not. (There's discussion in #153 about this).
  • When rspec-mocks is used but rspec-expectations is not, expect is not available. It's trivial to write one (it'll be < 10 lines of code both for the method and the class that it instantiates), but I need to figure out how to reliably define expect if and only if it is actually needed, because we don't want it overriding expect from rspec-expectations. (I've implemented this now in ee9d82e).
  • Lots of documentation updates are needed.

Please review and give your feedback!

@samphippen
Collaborator

This is just a comment on the first most obvious thing I saw: I like that you've prevented users from making nonsensical negations like allow(bees).not_to receive.

@samphippen
Collaborator

I'm not quite sure I follow the allow syntax, and I couldn't quite get this running. What does allow(x).to receive(:foo) do? Just based on the english reading it, I'd imagine that x is allowed to receive foo, does this mean that it's not allowed to receive anything else? Does x fail if foo is never called?

@myronmarston
Owner

@samphippen -- read the background in #153 for the story on allow. Basically, it's the new syntax for stubbing a method. I need to add docs for it, though.

myronmarston added some commits
@myronmarston myronmarston Add syntax configuration options. 0b40e0b
@myronmarston myronmarston Fix `any_instance` so it doesn't rely upon `should_receive`/`stub` be…
…ing on every object.
2264fd8
@myronmarston myronmarston Don't rely upon #null_object? being on every object.
This is based upon the logic in rspec/rspec-expectations@5fbe94a .

This is the last change we need to be able to use the :wrapped syntax with the :direct syntax disabled.
054e87f
@myronmarston myronmarston Normalize methods to symbols to get spec to pass on 1.8.7. 37cd6f4
@myronmarston myronmarston Remove obselete cucumber scenario.
With the changes for the new syntax, and the available config options,
`stub`, `should_receive` and `should_not_receive` are added to every
object initially (before RSpec::Mocks.setup) is called, but the config
can be set to remove them.
af7fa11
@myronmarston myronmarston Fully qualify all constants.
On 1.9.2 I was getting failures like:

uninitialized constant BasicObject::Hash
3d664b0
@myronmarston myronmarston Ensure the backtrace line is reported consistently.
MRI is different from JRuby and RBX in this regard. This should
get the travis build to pass, I hope.
f78297f
@myronmarston myronmarston Allow the new syntax to be used w/o rspec-expectations.
Here we conditionally define `expect` in a superclass module
so that it is available, but `RSpec::Matchers` can still be
included later to override it.

Note: with this in place, `expect` won't be undefined when the
new syntax is disabled.  I think that's OK, though.
ee9d82e
@samphippen
Collaborator

I decided to call the old syntax the :direct syntax because you call methods directly on the object...and the new syntax the :wrapped syntax because you wrap the object with a method like expect or allow. What do others think of these names?

This seems sensible to me, and I can't think of any better names right now.

@soulcutter
Collaborator

I think wrapped is really solid, but I'm not as sure about direct. To go with the opposite of wrapped, maybe bare?

@myronmarston

To me, "bare" implies the methods should have no receiver, (e.g: calling the on self).

@myronmarston myronmarston referenced this pull request in rspec/rspec-core
Closed

Aliasing API for #describe #870

@JonRowe
Owner

Do we have a feature describing this new behaviour? Seems like the quickest win for documentation...

@myronmarston

@JonRowe -- I'm planning to add both a cucumber feature and the YARD docs. I want to solidify the APIs (and the choices about which features we do or do not bring over from the old syntax) first -- otherwise I'll waste effort writing up docs for APIs that may change.

@JonRowe
Owner

That's cool, just feeding back is all ;)

@JonRowe
Owner

Incidentally I too dislike stub_chain but it is useful in circumstances where an API forces you to use method chaining, cough Arel.

@ghost

What about expect(Object, :any_instance).to receive(:foo)

@myronmarston

@burns -- that reads OK, but creates a funny situation where expect accepts a special :any_instance argument for receive, and otherwise does not accept other arguments. Plus expect is defined by rspec-expectations and I don't want rspec-mocks to monkey patch it.

@myronmarston

If we do want to support stub_chain with the new syntax, I suppose we could do something like:

allow(dbl).to receive_message_chain("a.b.c").and_return(5)

As for the current dbl.stub(:a => 1, :b: => 2) syntax, we could support that with:

allow(dbl).to receive_messages(:a => 1, :b => 2)

...or even:

allow(dbl).to receive(:a => 1, :b => 2)

Note that in both of these cases, it would allow the setting of multiple expectations for expect(dbl) -- which is a feature we didn't have before.

@dchelimsky -- when you have time, can you review this PR? I included a list of open questions in the PR message above.

@myronmarston myronmarston commented on the diff
features/outside_rspec/configuration.feature
@@ -16,10 +16,6 @@ Feature: configure any test framework to use rspec-mocks
should_not_receive
stub
- In order to give control to the consuming framework, none of these facilities
- are added until RSpec::Mocks::setup(self) is called. Simply requiring
- 'rspec/mocks' is not sufficient.
-
@myronmarston Owner

@dchelimsky -- this is one thing I was unsure about. Now that the syntax is configurable, it defaults to the :direct syntax when rspec-mocks is loaded but can be reconfigured to :wrapped, which removes the methods from all objects. Before it delayed when the methods get added...the reason given here is "to give control to the consuming framework", but I don't really understand that. Is it important to continue to delay when the methods get added, given that this gives users the ability to remove the methods by changing the config?

@dchelimsky Owner

IIRC people ran into trouble with respect to load order when rspec/mocks was required. Does that help?

@myronmarston Owner

It helps a bit. If nothing else, it suggests that the RC release(s) I'm planning is even more important.

@JonRowe Owner
JonRowe added a note

I'm pretty certain bundler causes some require order problems too, e.g. you want the setup happening after everything else.

@myronmarston Owner

@JonRowe -- I'm not sure what you mean...can you explain more?

@JonRowe Owner
JonRowe added a note

If I'm recalling correctly, RSpec::Mocks::setup(self) monkey patches the expectation (should_receive,should) methods onto self, and this needs to happen after other frameworks have finished monkey patching.

Bundler doesn't guarantee a load order when using the automatic require methods, hence the need to call this manually rather than have it performed on a require.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@jfelchner

@myronmarston I vote :+1: for only defining as_null_object on RSpec's objects. Currently I have an object which I want to define my own as_null_object on and it is causing issues because respond_to?(:as_null_object) is returning true no matter what object I throw at it.

No insurmountable but in the spirit of what you're trying to do, it's one more place to cut down on the surface area of RSpec's interface.

@JonRowe
Owner
I decided to call the old syntax the :direct syntax because you call methods directly
on the object...and the new syntax the :wrapped syntax because you wrap the object
with a method like expect or allow. What do others think of these names?

Those names make sense to me... but we could also use :should syntax and :expect syntax?

This time around, I'm thinking of only enabling the existing :direct syntax by default.

We should enable the :wrapped (:expect) syntax by default, because that's inline with the rest of RSpec no? I can appreciate the lack of desire to have two syntaxes but we need to make those calls eventually.

I didn't realize this, but the old syntax allowed any object to be as_null_object. I
personally think that only makes sense on a test double, not on a partial mock. 

I think this makes total sense. Very much :+1:

@samphippen
Collaborator

I like :expect and :should for the syntax names quite a lot. @myronmarston what do you think?

@jfelchner

@myronmarston I think :expect and :should for the syntax names are more clear and are also in line with rspec-expectations configuration option correct? I'm don't have a strong feeling about the names but I feel like rspec-expectations and rspec-mocks should match.

@myronmarston

Regarding naming the syntax options :expect and :should....I seriously considered it, but here's why I didn't (at least initially) choose that (but I'm still open to it):

  • For the new syntax in rspec-expectations, expect and should made tons of sense because they correspond to the methods you use to begin an expectation expression. Those are basically the only two methods involved. (Technically, there's also should_not, but that's just part of should).
  • For rspec-mocks, the existing syntax has many methods:
    • should_receive
    • should_not_receive
    • stub
    • stub!
    • unstub
    • unstub!
    • stub_chain
    • any_instance
  • Likewise, the new syntax has multiple methods:
    • expect (actually, this is added by rspec-expectations)
    • allow
    • receive
    • allow_any_instance_of
    • expect_any_instance_of
  • ...so should and expect don't seem to be very good summaries of these two syntaxes :(.
  • On top of that, one could use should with the new wrapped syntax: object.should receive(:foo).with(5). (Not that I'd recommend it, but I believe that would "just work").

Those of you recommending we use :expect and :should: do you still think those are the right names given these factors? (In retrospect, I kinda wish I had called the syntaxes :direct and :wrapped in rspec-expectations...)

@samphippen
Collaborator

So I agree with you that :should and :expect may not be the best summations of the new syntax. However: I think that our users know the two flavours of syntax as the "should" and "expect" syntax. As such I think we should use these names. Is it the case that we already use these names for rspec-expectations as @jfelchner says?

@dchelimsky
Owner

In the long run, I think it's a better outcome if these names align across rspec-expectations and rspec-mocks. i.e. if we go w/ direct/wrapped, let's do that for rspec-expectations as well. Even though it's already out there w/ should/expect, that can change - just need a rollout strategy (deprecation, etc).

@myronmarston

Is it the case that we already use these names for rspec-expectations as @jfelchner says?

Yep.

@samphippen
Collaborator

@dchelimsky regarding the rollout strategy do you think this is a deprecate in 2.14 -> remove in 3.0.0 thing or is that a little soon? I agree that we should sync them up regardless. I weakly prefer :expect and :should because it's what our users know and love at the moment but I could be convinced either way.

@JonRowe
Owner

I prefer expect and should, because it makes it clear which syntax we're referring to, I know it doesn't describe all the methods but in my head I know which ones are should and which ones are expect, so it makes sense.

@jfelchner

@myronmarston fair points. I actually hadn't thought that far into it, which is why you're in charge. :wink:

I still think that even though I agree your way is more logical, most users of RSpec who are actually going to change this setting will be fine with :expect and :should. Personally I'm fine with whatever but think that both rspec-expectations and rspec-mocks should sync up.

@myronmarston
Owner

Is anyone planning to code review this?

@dchelimsky
Owner

I might have some time later this week.

@samphippen
Collaborator

I'm having a look right now. I'll leave some comments

@samphippen samphippen commented on the diff
lib/rspec/mocks/targets.rb
@@ -0,0 +1,67 @@
+module RSpec
+ module Mocks
+ UnsupportedMatcherError = Class.new(StandardError)
+ NegationUnsupportedError = Class.new(StandardError)
+
+ class TargetBase
+ def initialize(target)
+ @target = target
+ end
+
+ def self.delegate_to(matcher_method, options = {})
+ method_name = options.fetch(:from) { :to }
+ define_method method_name do |matcher, &block|
@samphippen Collaborator

If this is going in 2.14 and needs to be backward compatible should this be an eval instead of a define method, or am I missing something?

@JonRowe Owner
JonRowe added a note

I believe eval is only needed over define_method when we have *args blobs as 1.8.6 doesn't support them.

@myronmarston Owner

No, I think @samphippen is right -- on 1.8.6 this'll yield a syntax error.

@JonRowe Owner
JonRowe added a note

My bad, @samphippen is correct, it's *args you can do on 1.8.6 and not &block got mixed up (knew you couldn't do one of them)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
spec/rspec/mocks/methods_spec.rb
@@ -2,29 +2,25 @@
module RSpec
module Mocks
- describe Methods, :if => (Method.method_defined?(:owner)) do
- def added_methods(klass, owner)
- some_object = klass.new
- (some_object.methods + some_object.private_methods).select do |method|
- some_object.method(method).owner == owner
- end.map(&:to_sym)
+ describe "Methods added to every object" do
+ include_context "with syntax", :wrapped
+
+ def added_methods
+ host = Class.new
+ orig_instance_methods = host.instance_methods
+ Syntax.enable_direct(host)
+ (host.instance_methods - orig_instance_methods).map(&:to_sym)
@samphippen Collaborator

I like this more than how it used to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@samphippen
Collaborator

I like most of this. I've left some comments. It seems that lots of the methods don't have docstrings. Do they need them? I suspect much of this is going to end up being private.

@JonRowe JonRowe commented on the diff
lib/rspec/mocks/matchers/have_received.rb
((50 lines not shown))
+ def apply_constraints_to(expectation)
+ @constraints.each do |constraint|
+ expectation.send(*constraint)
+ end
+ end
+
+ def ensure_count_unconstrained
+ if count_constraint
+ raise RSpec::Mocks::MockExpectationError,
+ "can't use #{count_constraint} when negative"
+ end
+ end
+
+ def count_constraint
+ @constraints.map(&:first).detect do |constraint|
+ COUNT_CONSTRAINTS.include?(constraint)
@JonRowe Owner
JonRowe added a note

Doing a chained map then detect makes me nervous (performance wise) cpi;d we streamline this into one loop? Or instead of the detect use the intersection operator?

@constraints.map { |constraints| constraints.first & COUNT_CONSTRAINTS }
@myronmarston Owner

This is existing code from #241. I simply moved it into the new matchers directory since I was adding the receive matcher.

You're right that there may be a way to optimize this, but on the surface your code snippet isn't obviously faster to me. (Plus it returns an array, not a single constraint). If you want to take a stab at benchmarking it and changing it in another PR, have at it. With the array only having 5 elements, I'm not terribly concerned.

@JonRowe Owner
JonRowe added a note

It's a 5x multiplier on the outer array, that's my only concern. I'll take a look at it after it's merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@JonRowe
Owner

I've been over this a few times now @myronmarston and I'm pretty happy with it :) You've done an awesome job, I've added a bit more 2¢ on a couple of things but mostly I'm still only really noticing the lack of a .feature file ;)

samphippen added some commits
@samphippen samphippen Change :direct and :wrapped for :should and :expect.
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
bc04bd0
@samphippen samphippen Add a .feature for the new expect syntax.
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
f7d7676
@samphippen
Collaborator

@myronmarston @soulcutter @alindeman @JonRowe I've just written a .feature for this. It's my first one so any comments would be appreciated :)

@samphippen
Collaborator

I knew I forgot someone: @dchelimsky if you'd also take a look that'd be great.

features/message_expectations/expect_syntax.feature
@@ -0,0 +1,148 @@
+Feature: the expect syntax for message expectations
+
+ Use expect(receiver).to receive(:message) to set an expectation that
@JonRowe Owner
JonRowe added a note

shouldn't expect(receiver).to receive(:message) be in backticks? expect(receiver).to receive(:message)

@samphippen Collaborator

yes it should :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
features/message_expectations/expect_syntax.feature
@@ -0,0 +1,148 @@
+Feature: the expect syntax for message expectations
+
+ Use expect(receiver).to receive(:message) to set an expectation that
+ `receiver` should recieve the message `:message` before the example is
@JonRowe Owner
JonRowe added a note

receive the message...

@samphippen Collaborator

:D speeling is hard

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
features/message_expectations/expect_syntax.feature
((29 lines not shown))
+ class Account
+ attr_accessor :logger
+
+ def close
+ logger.account_closed
+ end
+ end
+ """
+ And a file named "spec/spec_helper.rb" with:
+ """ruby
+ RSpec.configure do |config|
+ config.mock_with :rspec do |mocks|
+ mocks.syntax = :expect
+ end
+ end
+
@JonRowe Owner
JonRowe added a note

cough white space

@samphippen Collaborator

this is now fixed, but the comment still lives on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@samphippen samphippen Clean up expect_syntax.feature.
Review from @JonRowe.

Signed-off-by: Sam Phippen <samphippen@googlemail.com>
7a7643e
@JonRowe
Owner

The .feature looks pretty good to me; One thing that... irks... me is:

 And a file named "spec/spec_helper.rb" with:
 """ruby
 RSpec.configure do |config|
   config.mock_with :rspec do |mocks|
     mocks.syntax = :expect
   end
 end

I'm in two minds about it, on the one hand it nicely documents how to setup this syntax, on the other hand it feel's like it should be compressed out the way, as it's not totally relevant to the feature at hand... I think I'd like to see a background step

Background:
  Given there is a spec helper setting syntax to `:expect`

but I'd also be open to simply moving that block from the scenarios into a background.

@samphippen
Collaborator

Inserting some clarity:
(from IRC)

[00:08:18] <Sou|cutter>  samphippen: oooh, your first cuke eh? :)
[00:08:24] <samphippen>  not my first
[00:08:26] <samphippen>  I mean first on rspec
[00:08:32] <Sou|cutter>  oh ok :)
samphippen and others added some commits
@samphippen samphippen Move the spec_helper create in expect_syntax.feature to a background.
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
4af8d70
@soulcutter soulcutter Rename `receiver` to `object` and tighten up feature slightly 1a5a5b1
@samphippen samphippen Merge branch 'master' into new_syntax
Signed-off-by: Sam Phippen <samphippen@googlemail.com>

Conflicts:
	lib/rspec/mocks/have_received.rb
	lib/rspec/mocks/method_double.rb
87efdd7
@samphippen
Collaborator

@myronmarston I've merged this up with master. One concern: I think we should enable both syntaxes by default. The reason for this is that we prefer the expect syntax everywhere else. It seems like it may introduce cognitive dissonance if we prefer one syntax for one thing, but disable it for the other thing by default. WDYT?

@dchelimsky
Owner

@samphippen late to the party, but ... there are now two features: expect_message.feature and expect_syntax.feature, which read "expect a message" and "the expect syntax for message expectations". Each one makes sense on its own but I'd like to align them better, or perhaps merge them, or perhaps split them into files by sub-feature (expect message, expect message w/ args, etc). I'm going to play with this a bit and push to a branch if I come up with something I like.

@myronmarston
Owner

One concern: I think we should enable both syntaxes by default. The reason for this is that we prefer the expect syntax everywhere else. It seems like it may introduce cognitive dissonance if we prefer one syntax for one thing, but disable it for the other thing by default. WDYT?

I'm on the fence about this one. For rspec-expectations we had to enable both syntaxes by default due to backwards compatibility -- since the expect block form had been around for a long time. Here we don't have to enable both (which is why I didn't initially -- the thought being that folks will want to use one or the other rather than both), but I'm open to doing so. I don't have a strong preference. I'm happy to defer to whatever the majority community preference is here.

@dchelimsky
Owner

@samphippen Take a look at d8369b7. WDYT?

@samphippen
Collaborator

@dchelimsky I like what you've done. Care to merge it into this branch?

@JonRowe
Owner

Took the liberty of picking across ;)

@dchelimsky
Owner

Thanks @JonRowe

@samphippen
Collaborator

I've put together this gist to ask people to express their preferences. I'd like feedback today before sending it out to the community at large via the twitter/mailing list.

edit: @JonRowe @myronmarston @soulcutter @alindeman @dchelimsky if you could take a look and tell me what you think that'd be awesome :cat:

@JonRowe
Owner

Nicely worded :)

@samphippen
Collaborator

I'm basically wondering whether we should add some of the reasoning for the new syntax being the default in the gist?

@JonRowe
Owner

Sure, but I'd keep it brief.

@samphippen
Collaborator

Ok, I've done that. Feel free to take a look.

@dchelimsky
Owner
@samphippen
Collaborator

@dchelimsky I've reworded that now. WDYT?

@dchelimsky
Owner

Looks good, thanks.

@myronmarston
Owner
@samphippen
Collaborator

Ok. Looks like people want both on by default. Should I do that, update the cuke, wait for travis and then merge?

@myronmarston

Ok. Looks like people want both on by default. Should I do that, update the cuke, wait for travis and then merge?

:+1:

samphippen added some commits
@samphippen samphippen Enable the :expect syntax by default.
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
563e2f5
@samphippen samphippen Add a changelog entry for #266.
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
5639d34
@samphippen samphippen merged commit ae03e63 into master

1 check passed

Details default The Travis CI build passed
@myronmarston

Thanks, @samphippen!

Looking over the diff one more time I noticed there are still places that reference the :wrapped syntax. I think these need to be updated -- want to take a stab at it?

spec/rspec/mocks/methods_spec.rb
6:      include_context "with syntax", :wrapped

spec/rspec/mocks/null_object_mock_spec.rb
107:    describe "when using the :wrapped syntax" do
108:      include_context "with syntax", :wrapped
@samphippen
Collaborator
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Apr 4, 2013
  1. @myronmarston
  2. @myronmarston
Commits on Apr 8, 2013
  1. @myronmarston
  2. @myronmarston
  3. @myronmarston

    Don't rely upon #null_object? being on every object.

    myronmarston authored
    This is based upon the logic in rspec/rspec-expectations@5fbe94a .
    
    This is the last change we need to be able to use the :wrapped syntax with the :direct syntax disabled.
  4. @myronmarston
  5. @myronmarston

    Remove obselete cucumber scenario.

    myronmarston authored
    With the changes for the new syntax, and the available config options,
    `stub`, `should_receive` and `should_not_receive` are added to every
    object initially (before RSpec::Mocks.setup) is called, but the config
    can be set to remove them.
  6. @myronmarston

    Fully qualify all constants.

    myronmarston authored
    On 1.9.2 I was getting failures like:
    
    uninitialized constant BasicObject::Hash
  7. @myronmarston

    Ensure the backtrace line is reported consistently.

    myronmarston authored
    MRI is different from JRuby and RBX in this regard. This should
    get the travis build to pass, I hope.
Commits on Apr 9, 2013
  1. @myronmarston

    Allow the new syntax to be used w/o rspec-expectations.

    myronmarston authored
    Here we conditionally define `expect` in a superclass module
    so that it is available, but `RSpec::Matchers` can still be
    included later to override it.
    
    Note: with this in place, `expect` won't be undefined when the
    new syntax is disabled.  I think that's OK, though.
Commits on Apr 18, 2013
  1. @myronmarston
  2. @myronmarston
  3. @myronmarston

    Improve the way we make `expect` available when rspec-expectations is…

    myronmarston authored
    … not used.
    
    - Put it in a named rather than anonymous module.
    - Allow the syntax to be toggled.
Commits on May 7, 2013
  1. @samphippen

    Change :direct and :wrapped for :should and :expect.

    samphippen authored
    Signed-off-by: Sam Phippen <samphippen@googlemail.com>
  2. @samphippen

    Add a .feature for the new expect syntax.

    samphippen authored
    Signed-off-by: Sam Phippen <samphippen@googlemail.com>
  3. @samphippen

    Clean up expect_syntax.feature.

    samphippen authored
    Review from @JonRowe.
    
    Signed-off-by: Sam Phippen <samphippen@googlemail.com>
  4. @samphippen

    Move the spec_helper create in expect_syntax.feature to a background.

    samphippen authored
    Signed-off-by: Sam Phippen <samphippen@googlemail.com>
  5. @soulcutter
Commits on May 8, 2013
  1. @samphippen

    Merge branch 'master' into new_syntax

    samphippen authored
    Signed-off-by: Sam Phippen <samphippen@googlemail.com>
    
    Conflicts:
    	lib/rspec/mocks/have_received.rb
    	lib/rspec/mocks/method_double.rb
  2. @dchelimsky @JonRowe

    align expect_message* cukes

    dchelimsky authored JonRowe committed
Commits on May 10, 2013
  1. @samphippen

    Enable the :expect syntax by default.

    samphippen authored
    Signed-off-by: Sam Phippen <samphippen@googlemail.com>
  2. @samphippen

    Add a changelog entry for #266.

    samphippen authored
    Signed-off-by: Sam Phippen <samphippen@googlemail.com>
Something went wrong with that request. Please try again.