Skip to content

3.6.0 release post #105

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
May 5, 2017
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
94 changes: 94 additions & 0 deletions source/blog/2017-04-27-rspec-3-6-has-been-released.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
---
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to update the date in the filename!

title: RSpec 3.6 has been released!
author: Sam Phippen, TODO: other editors
---

RSpec 3.6 has just been released! Given our commitment to
[semantic versioning](http://semver.org/), this should be a trivial
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For readability I think this could be "this should be an easy upgrade"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is copied word for word from the previous post. I'll make your change, as I think it's better. We should standardise this blog post into a template.

upgrade for anyone already using RSpec 3, but if we did introduce
any regressions, please let us know, and we'll get a patch release
out with a fix ASAP.

RSpec continues to be a community-driven project with contributors
from all over the world. This release includes over XXX commits and YYY
merged pull requests from over 50 different contributors!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's funny that you have the contributor count filled in but not the commits and PRs! Usually I fill this in after generating the stats as it is based on that.


Thank you to everyone who helped make this release happen!

## Notable Changes

### Core: Failure counts of errors occurring outside examples
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, the fact that we count failures is less interesting than the fact that we handle these errors at all. Before the changes in RSpec 3.6 (such as rspec/rspec-core#2323), errors that occurred in :suite hooks or while loading spec files would just crash the ruby interpreter and you'd get ruby's default error output including a full stacktrace. Now we handle these errors and provide nicely formatted output, including backtrace filtering, error-site code snippet, and mentioning the count of these errors in the summary output.

WDYT of this instead?


Core: Errors outside examples now handled and formatted well

In previous versions of RSpec, we allowed errors encountered while loading spec files or running :suite hooks to crash the ruby interpreter, giving you its default full-stacktrace output. In RSpec 3.6, we now handle all errors that occur outside examples, and format them nicely including a filtered backtrace and a code snippet for the site of the error. For example, an error in a before(:suite) hook is now formatted like this:

screen shot 2017-04-27 at 9 59 12 pm

Thanks to Jon Rowe for assisting with this feature.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pasted verbatim.


In previous versions of RSpec, when errors occurred outside of examples, they
could potentially have side effects like preventing examples from running, or
stopping nested example groups from being defined. To help debug those issues,
RSpec now prints when those errors occur in the end of run summary, for
example:

~~~
Finished in 0.00033 seconds (files took 0.14097 seconds to load)
0 examples, 0 failures, 1 error occurred outside of examples
~~~

Special thanks to Jon Rowe for adding this feature.

### Core: `config.fail_if_no_examples`

As it currently stands RSpec will exit with code `0` indicating success if no
examples are defined. This configuration option makes it possible to cause RSpec
to exit with code `1` indicating failure, which is useful for CI environments.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better to more explicitly explain why this is useful--i.e. it helps detect when you've misconfigured RSpec to look for specs in the wrong place or with the wrong pattern and it therefore can't find any. Instead of always passing, this makes it fail in that case.


~~~ ruby
RSpec.configure do |config|
config.fail_if_no_examples = true
end
~~~

A special thanks to Ewa Czechowska for getting this in to core.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before moving on to the expectations changes, there's one more notable core changes, IMO: color is automatically enabled if RSpec is outputting to a TTY, so there's no longer a need to set --color to opt-in to this behavior. If you really want color (even if the output isn't a TTY), you can pass --force-color, or --no-color to disable color output. Can you add a section on that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

### Expectations: Scoped alised and negative matchers
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*aliased


TODO: is anyone more familiar with this feature who could full this out?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically, the idea is that you can now call alias_matcher or define_negated_matcher in an example group to limit the scope of the newly defined matchers to just that group, rather than them being defined globally for use from all groups.


### Mocks: `without_partial_double_verification`

When we released RSpec 3.0 we added [verifying doubles](http://rspec.info/blog/2014/05/notable-changes-in-rspec-3/#verifying-doubles).
Verifying doubles allow you to ensure that stubs and mocks that you create with
RSpec correctly emulate the interfaces on the objects in your tests.
`without_partial_double_verification` allows you to turn off the verifying
double behaviour for the duration of the execution of a block. For example:

~~~ ruby
class Widget
def call(takes_an_arg)
end
end

RSpec.describe Widget do
it 'can be stub with a mismatched arg count' do
without_partial_double_verification {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why curlies here instead of do/end?

w = Widget.new
allow(w).to receive(:call).with(1, 2).and_return(3)
w.call(1, 2)
}
end
end
~~~

here, this test would fail if the `without_partial_double_verification` call was
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/here/Here/

not made, because we are stubbing the `call` method on the `Widget` object
with an argument count that is different to the implementation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The explanation for this feature makes it sound like this would never be useful. Can you provide a rationale for why this was added (I think it's useful in some kind of rspec-rails context?)


A special thanks to Jon Rowe for adding this feature.

### Rails: Support for Rails 5.1:

RSpec 3.6.0 comes with full support for Rails 5.1. There are no major changes to
the rails 5.1 API and so this upgrade should be fully smooth. Simply bumping to
the latest version of RSpec will bring the support to your app with no other
changes required on your part
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth mentioning that system tests are not yet supported?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This last sentence is missing a period.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth mentioning that system tests are not yet supported?

Correct me if I'm wrong, but based on my reading of the system tests section of the 5.1 release announcement, it sounds like system tests are what rspec-rails users have had for years when they install capybara and write :feature specs.

Or is there more to system tests then that? If there's not, saying "system tests are not yet supported" sends the wrong message--it makes it sound like "system tests" are a compelling thing offered by the default rails testing setup that rspec-rails lacks. Instead, something like "Rails 5.1 added a feature called system tests, which brings parity to the feature tests rspec-rails and capybara have offered for years" might be better. (But only if that's accurate; I'm not sure if it is).



## Stats:

TODO when ready to release
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To generate this, run rake "version_stats[v3.5.0...v3.6.0]" in rspec-dev once you've tagged all the repos with v3.6.0.

Also, we usually include a Docs section and a Release Notes section in these blog posts (take a look at the 3.5 or 3.4 posts for an example).

For the release notes, we have an rspec-dev task (release_notes) to assist. That said, it would be good to combine the release notes from all 3.6 betas here, which I don't think it does. Maybe you can combine those by hand as I did for the 3.5 blog post?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍