-
-
Notifications
You must be signed in to change notification settings - Fork 41
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
3.6.0 release post #105
Changes from 1 commit
baf323a
7140a7e
f8a103f
14eb7ad
791878a
f2b421f
b45aa1d
b859c7c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,94 @@ | ||
--- | ||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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" There was a problem hiding this comment. Choose a reason for hiding this commentThe 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! | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 WDYT of this instead? Core: Errors outside examples now handled and formatted wellIn previous versions of RSpec, we allowed errors encountered while loading spec files or running Thanks to Jon Rowe for assisting with this feature. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. done |
||
### Expectations: Scoped alised and negative matchers | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Basically, the idea is that you can now call |
||
|
||
### 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 { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why curlies here instead of |
||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it worth mentioning that system tests are not yet supported? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This last sentence is missing a period. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To generate this, run Also, we usually include a For the release notes, we have an rspec-dev task ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 |
There was a problem hiding this comment.
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!