More progress.

Author: myronmarston

source/blog/2015-05-28-rspec-3-3-has-been-released.md

@@ -3,7 +3,7 @@ title: RSpec 3.3 has been released!
 author: Myron Marston
 ---
 
-RSpec 3.2 has just been released! Given our commitment to
+RSpec 3.3 has just been released! Given our commitment to
 [semantic versioning](http://semver.org/), this should be a trivial
 upgrade for anyone already using RSpec 3.0, 3.1 or 3.2, but if we did introduce
 any regressions, please let us know, and we'll get a patch release
@@ -46,7 +46,7 @@ top-level group defined in `spec/unit/baseball_spec.rb`.
 
 For the most part, the new example IDs are primarily used internally by
 RSpec to support some of the new 3.3 features, but you're free to use
-them from the command line, and the re-run command printed by RSpec for
+them from the command line. The re-run command printed by RSpec for
 each failure will use them if the file location does not uniquely
 identify the failed example. Copying and pasting the re-run command
 for a particular failed example will always run just that example now!
@@ -101,7 +101,7 @@ without paying the cost of repeatedly running the entire suite. RSpec
 3.3 includes a new option that vastly simplifies this work flow:
 
 ~~~
-rspec --next-failure
+$ rspec --next-failure
 # or apply it to a specific file or directory:
 $ rspec spec/unit --next-failure
 ~~~
@@ -175,7 +175,7 @@ and want to avoid that overhead, you can configure RSpec to
 ### Expectations: New `aggregrate_failures` API
 
 When you've got multiple independent expectations to make about a
-particular result, you've generally got two routes you can take. One way is
+particular result, there's generally two routes you can take. One way is
 to define a separate example for each expectation:
 
 ~~~ ruby
@@ -235,7 +235,7 @@ RSpec.describe Client do
 end
 ~~~
 
-Within the `aggregate_failures` block, expectations do not cause the
+Within the `aggregate_failures` block, expectations failures do not cause the
 example to abort. Instead, a single _aggregate_ exception will be
 raised at the end containing multiple sub-failures which RSpec will
 format nicely for you:
@@ -316,8 +316,8 @@ Failure/Error: expect([foo]).to include(bar)
 ~~~
 
 In addition, RSpec's improved formatting for `Time` and other objects will
-now be used wherever those objects are inspected for every matcher. So, for
-example, where you used to get this:
+now be used wherever those objects are inspected, regardless of which
+built-in matcher you used. So, for example, where you used to get this:
 
 ~~~
 Failure/Error: expect([Time.now]).to include(Time.now)
@@ -342,9 +342,73 @@ these improvements!
 
 ### Mocks: Improved Failure Output
 
+RSpec::Mocks has also received some nice improvements to its failure output. RSpec's
+improved formatting for `Time` and other objects is now applied to mock expectation
+failures as well:
+
+~~~
+Failure/Error: dbl.foo(Time.now)
+  #<Double (anonymous)> received :foo with unexpected arguments
+    expected: (2015-06-09 08:33:36.865827000 -0700)
+         got: (2015-06-09 08:33:36.874197000 -0700)
+  Diff:
+  @@ -1,2 +1,2 @@
+  -[2015-06-09 08:33:36.865827000 -0700]
+  +[2015-06-09 08:33:36.874197000 -0700]
+~~~
+
+In addition, the failure output for `have_received` has been much improved so that when
+the expected args do not match, it lists each set of actual args, and the number of
+times the message was received with those args:
+
+~~~
+Failure/Error: expect(dbl).to have_received(:foo).with(3)
+  #<Double (anonymous)> received :foo with unexpected arguments
+    expected: (3)
+         got: (1) (2 times)
+              (2) (1 time)
+~~~
+
+Thanks to John Ceh for implementing the latter improvement!
+
 ### Mocks: Stubbing `MyClass.new` Verifies Against `MyClass#initialize`
 
-### Rails: ?
+RSpec's [verifying doubles
+(TODO)](https://relishapp.com/rspec/rspec-mocks/v/3-2/docs/verifying-doubles)
+use the metadata that Ruby's reflection capabilities provide to verify,
+among other things, that passed arguments are valid according to the
+original method's signature. However, when a method is defined using
+just an arg splat:
+
+~~~ ruby
+def method_1(*args)
+  method_2(*args)
+end
+
+def method_2(a, b)
+end
+~~~
+
+...then the verifying double is going to allow _any_ arguments, even
+if the method simply delegates to _another_ method that does have a
+strong signature. Unfortunately, `Class#new` is one of these methods.
+It's defined by Ruby to delegate to `#initialize`, and will only accept
+arguments that the signature of `initialize` can handle, but the metadata
+provided by `MyClass.method(:new).parameters` indicate it can handle any
+arguments, even if it can't.
+
+In RSpec 3.3, we've improved verifying doubles so that when you stub
+`new` on a class, it uses the method signature of `#initialize` to
+verify arguments, unless you've redefined `new` to do something
+different. This allows verifying doubles to give you an error when
+you pass arguments to a stubbed `MyClass#new` method that the real
+class would not allow.
+
+### Rails: Add support for PATCH to route specs created via scaffold.
+
+### Rails: Add support for ActiveJob specs as standard
+RSpec::Rails::RailsExampleGoups via both :type => :job and inferring
+type from spec directory spec/jobs.
 
 ## Stats