RSpec's plans for sorbet

I have been recently adopting sorbet into my projects and it greatly helped me with refactoring.

Unfortunately the typechecking errors are not extending to specs due to the DSL nature of RSpec (in general all _spec.rb files have to be typed: false).

I know that there is a project to address some of the runtime issues resulting from using rspec-mocks but I am more talking about the static checking before running the tests. It would achieve a lot of development speed when I could see which problems I need to fix in my spec without running them.

So I am wondering what the general opinion of the RSpec team is. Do you see sorbet features slowly being integrated into the framework or do you know of any third party projects that combine the strict typechecks with the dynamic nature of RSpec.

https://relishapp.com/rspec shows application error

Currently https://relishapp.com/rspec shows application error.

Could you investigate it?

Related issue: #70 , rspec/relish-root-repo#5

Expectation count in spec summary

Hello,

Minitest provides a nice statistic regarding number of passed assertions:

% ruby -Ilib:test test/minitest/test_minitest_test.rb
Run options: --seed 37685

# Running:

...................................................................... (etc)

Finished in 0.107130s, 1446.8403 runs/s, 2959.0217 assertions/s.

155 runs, 317 assertions, 0 failures, 0 errors, 0 skips

here I'm referring to 317 assertions.

is there an analogue way in RSpec to show the number of passed expectations?

Thanks!

Document the fact that lets run in parallel, and let!s (apparently) do not

I've been going crazy trying to understand why these rspecs fail randomly.
There are active models each created in a let, and then interdependencies between the lets.
Firstly, I haven't seen any documentation to say that lets are executed in parallel on multiple threads (they seem to be). This fact can be very important to realise.
Secondly, its not explicitly stated that (I assume) let!s are run serially as a result of being put together into a before hook. If they are not, there needs to be a way to specify lets that are executed single threaded serially.
config.threadsafe I think is a different thing - it makes each let threadsafe individually, but still allows two lets to execute in parallel.

Trouble stubbing YAML.load_file

Here's a snippet

The class where I'm loading YAML file

class FeatureStorageService
  FEATURES = YAML.load_file(Rails.root.join("config/features.yml"))
end

The test

describe FeatureStorageService do
  let!(:yaml)     { YAML.load_file(Rails.root.join("spec/factories/files/features.yml")) }

  before do
    allow(YAML).to receive(:load_file).and_call_original
    allow(YAML).to receive(:load_file).with(Rails.root.join("config/features.yml")).and_return(yaml)
  end
end

The spec doesn't load the file at "spec/factories/files/features.yml" instead loads the original one.
I have cross checked the syntax so many times.

Also, the stubbing works fine for my controller spec which is accessing the same service(class shown here) with the same syntax.

Dependencies:
gem 'rspec-rails', '~> 3.4.2'
gem 'rails', '4.2.7'

Running Requests specs consistently fail on GitHub Actions CI

Hi there,

Let me know if this issue is better suited to Stack Overflow, but I am consistently getting this error on all get request specs:
TypeError: no implicit conversion of nil into String

The tests pass when I run rspec locally, but when running on GitHub Actions CI, they fail every single time. The error messages don't give me any indication of what's going on, and because I can't reproduce it locally, I'm not sure how to debug.

https://relishapp.com/rspec can not open

https://relishapp.com/rspec

RSpec - how to change format to more concise output

Hi Rspec team, your gem is awesome!

I can run RSpec like this and output is really large

$ rspec spec/interactors/reports/create_spec.rb          
Run options: include {:focus=>true}                                                                                                                   
                                                                                                                                                      
Randomized with seed 26531                                                                                                                            
                                                                                                                                                      
  1) Reports::Create when params are valid successfully creates report                                                                                
     Failure/Error: report.assignees.create!(profile: contact, confirmed: true, owner: true) if create_assignee?
      
     NoMethodError:                                                                                                                                   
       undefined method `assignees' for nil:NilClass
     # ./app/interactors/reports/create.rb:25:in `create_report!'
     # ./app/interactors/reports/create.rb:10:in `block in call'   
     # .. a lot of trace lines
Top 1 slowest examples (0.37224 seconds, 84.5% of total time):
  Reports::Create when params are valid successfully creates report
    0.37224 seconds ./spec/interactors/reports/create_spec.rb:52

Finished in 0.44068 seconds (files took 4.44 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/interactors/reports/create_spec.rb:52 # Reports::Create when params are valid successfully creates report

I want to have the ability to output only these lines

$ rspec spec/interactors/reports/create_spec.rb          
  1) Reports::Create when params are valid successfully creates report                                                                                
     Failure/Error: report.assignees.create!(profile: contact, confirmed: true, owner: true) if create_assignee?
     NoMethodError:                                                                                                                                   
       undefined method `assignees' for nil:NilClass
     # ./app/interactors/reports/create.rb:25:in `create_report!'

Without detailed stats in the end and detailed backtrace

The goal of this - I want to set up my guard notification gracefully with rspec => So that I will see an error in the OS notification without scrolling to the top of the terminal to see the reason for the error

In Rspec --help I found only notice about --format custom formatter class name , but how to use it ? ( Do you have any examples ?)

Can we send tags with regex?

Hi,

I have a requirement for my rspec tests. I have a bunch of tests in a folder tagged with different tags, but all these tags start with "FR_". Similarly I have some other tests in same which do not have this tag at all.

Is there way which I can find the tests which doesn't have these "FR_" tag with --dry-run or any command.

Regards,
Kalyan Uppalapati

Not able to access class methods in spec even after including the module

I am trying to access a class method in spec by calling it through ClassName.method_name. I have included the module of the class in spec under RSpec.configure block but still I am not able to access the method. Please refer below spec file and class file
spec file

require './lib/pages/OCBC/open_account.rb'

RSpec.configure do |configure|
 configure.include OCBC
end

describe 'Test' do
 it "tests the module" do
  OpenAccount.name
 end
end

Class file

module OCBC
 class OpenAccount
  def self.name
   puts 'Akash'
  end
end

Error

NameError: uninitialized constant OpenAccount

However, when I am including module outside RSpec.configure block(as shown below), I am able to access the class method

require './lib/pages/OCBC/open_account.rb'

include OCBC

describe 'Test' do
 it "tests the module" do
  OpenAccount.name
 end
end

Rspec might be unzipping the gzipped HTTP request body but not changing the encoding

Hi!

I am trying to find which gem is unzipping the gzipped HTTP response body (as described here trusche/httplog#58 and here googleapis/google-api-ruby-client#661 (comment)), and have found that this happens only when running it from the rspec test.

So wanted to ask if that might be the case?
Basically, what's happening, is that when sending request to Google Cloud API, the response should come as gzipped body, but the httplog gets the body already unzipped, but with the encoding of the gzip. So it tries to unzip it again and fails.

Is rspec unzipping gzipped body? If yes, can it also change the encoding to not be the gzip?

Thanks!

Maris

Mismatch in released rspec and rspec-core versions

Hi,

As part of our build process, we have a few different gems that install rspec and rspec-core (both at the latest versions). We are now running in to an issue as a new version of rspec-core was released earlier today (which in itself is fine) but due to the runtime dependencies of rspec (defined here), we are no longer able to run any builds.

As rspec v3.8.0 (currently the latest) depends on rspec-core, rspec-expectations and rspec-mocks v3.8.0 (which are no longer the latest).

I do see a commit in rspec to push to v3.9.0 here; would it be possible to publish the new version of the gem? If not, please advise of a way we can work around this dependency issue.

Thanks!

Trouble mocking stubing a class

Hi!

I'm trying to stub a class that returns an OpenStruct like this:

        body = {
          "bmx": {
            "series":[
              "datos"
            ]
          }
        }
        response = OpenStruct.new(body: body)
        http = OpenStruct.new(get: response)
        result = OpenStruct.new(http: http)

but always the object returned is the latest (body) and not result

        allow(Banxico::Series::ExchangeRate).to receive(:new).and_return(result)

      Banxico::Series::ExchangeRate.new
     => #<OpenStruct http=#<OpenStruct get=#<OpenStruct body={:bmx=>{:series=>["datos"]}}>>>

Is this a bug?

What would be needed for RSpec to fully support TruffleRuby?

We had some discussions about this years ago but I think it's time to clarify the requirements.

Of course, TruffleRuby would need pass the RSpec test suite, I think it's quite close to that if not already the case.
Maybe @gogainda or @bjfish can check that by running the CI on forks, adding truffleruby to the matrix, and report the results here.

Anything else?

When TruffleRuby already runs Rails and is already in many other gems CI, it does feel weird that such a common gem as RSpec doesn't officially support or test TruffleRuby in CI.
OTOH AFAIK RSpec already works fine on TruffleRuby in practice for running specs, I don't remember any issue running RSpec on TruffleRuby in many years.

If the concern is adding TruffleRuby in CI would slow down development due to e.g. longer CI times for PRs, I think an easy way to address that would be to make the CI job a daily or weekly one.
Still, I think we should measure if it adds any time for a PR workflow and how much, per rspec repo (e.g., maybe rspec-rails takes a while and rspec-support takes very little time).

Another concern I remember is wanting a release of truffleruby in CI, and not truffleruby-head in CI.
That's fine, it might just take a bit longer to wait for the next release.

Issues with Rspec tests for Travis CI randomly failing from time to time

See example Travis CI build: https://travis-ci.org/duracelltomi/gtm4wp/jobs/380080993 - Randomly it all goes through but sometimes fails for no reason, and would work again on some builds. Example repo where the test code is kept is: https://github.com/koconder/wordpress-test-template/tree/master/spec

In the travis ci build you can see

[Thu May 17 08:02:50 2018] 127.0.0.1:41748 Invalid request (Unexpected EOF)

Relating to:

RSpec::Retry: 2nd try ./baseline.rb:21
RSpec::Retry: 3rd try ./baseline.rb:21
F
RSpec::Retry: 2nd try ./baseline.rb:25
RSpec::Retry: 3rd try ./baseline.rb:25
F
RSpec::Retry: 2nd try ./baseline.rb:30
RSpec::Retry: 3rd try ./baseline.rb:30
F
Cleaning up...
Failures:
  1) WordPress: http://localhost:12000/ -  frontpage Healthy status code 200, 301, 302, 503
     Failure/Error: expect(page).to have_status_of [200,301,302,503]
       expected #<Capybara::Session> to have status of 200, 301, 302, and 503
     # ./baseline.rb:22:in `block (3 levels) in <top (required)>'
     # /home/travis/.rvm/gems/ruby-2.4.1/gems/rspec-retry-0.4.0/lib/rspec/retry.rb:43:in `block (3 levels) in apply'
     # /home/travis/.rvm/gems/ruby-2.4.1/gems/rspec-retry-0.4.0/lib/rspec/retry.rb:34:in `times'
     # /home/travis/.rvm/gems/ruby-2.4.1/gems/rspec-retry-0.4.0/lib/rspec/retry.rb:34:in `block (2 levels) in apply'
  2) WordPress: http://localhost:12000/ -  frontpage Page includes stylesheets
     Failure/Error: expect(page).to have_css
       expected #<Capybara::Session> to have css
     # ./baseline.rb:26:in `block (3 levels) in <top (required)>'
     # /home/travis/.rvm/gems/ruby-2.4.1/gems/rspec-retry-0.4.0/lib/rspec/retry.rb:43:in `block (3 levels) in apply'
     # /home/travis/.rvm/gems/ruby-2.4.1/gems/rspec-retry-0.4.0/lib/rspec/retry.rb:34:in `times'
     # /home/travis/.rvm/gems/ruby-2.4.1/gems/rspec-retry-0.4.0/lib/rspec/retry.rb:34:in `block (2 levels) in apply'
  3) WordPress: http://localhost:12000/ -  frontpage Page includes javascript
     Failure/Error: expect(page).to have_js
       expected #<Capybara::Session> to have js
     # ./baseline.rb:31:in `block (3 levels) in <top (required)>'
     # /home/travis/.rvm/gems/ruby-2.4.1/gems/rspec-retry-0.4.0/lib/rspec/retry.rb:43:in `block (3 levels) in apply'
     # /home/travis/.rvm/gems/ruby-2.4.1/gems/rspec-retry-0.4.0/lib/rspec/retry.rb:34:in `times'
     # /home/travis/.rvm/gems/ruby-2.4.1/gems/rspec-retry-0.4.0/lib/rspec/retry.rb:34:in `block (2 levels) in apply'
Finished in 6 minutes 41 seconds (files took 0.70182 seconds to load)
3 examples, 3 failures
Failed examples:
rspec ./baseline.rb:21 # WordPress: http://localhost:12000/ -  frontpage Healthy status code 200, 301, 302, 503
rspec ./baseline.rb:25 # WordPress: http://localhost:12000/ -  frontpage Page includes stylesheets
rspec ./baseline.rb:30 # WordPress: http://localhost:12000/ -  frontpage Page includes javascript
The command "cd wp-tests/spec && bundle exec rspec *.rb" exited with 1.

Also not sure if there is a ruby/rvm issue with the:

sh: 1: wp: not found
sh: 1: wp: not found
sh: 1: wp: not found

Using the non-global describe causes a spec to fail when using vcr

Hi all!

I'm using rspec + vcr and I have the weirdest freaking error I have ever seen.

When I make this change:

My test goes from:

PaymentProcessingService
  .capture_charge
    stripe
      should work if authorization is missing

Finished in 9.32 seconds (files took 16.33 seconds to load)
1 example, 0 failures

PaymentProcessingService
  .capture_charge
    stripe
      should work if authorization expired/has been refunded (FAILED - 1)

Failures:

  1) PaymentProcessingService.capture_charge stripe should work if authorization expired/has been refunded
     Failure/Error:
       raise Sneakers::PaymentFailedError.new(
           message: error[:code] || error[:message],
           amount_cents: payment_breakdown[:charge_amount_cents],
           transaction_id: error[:charge],
           fraud: error[:code] == 'card_declined' && ['fraudulent', 'lost_card', 'stolen_card'].include?(error[:decline_code]),
           decline_code: error[:decline_code]
       )

     Sneakers::PaymentFailedError:
       You cannot use a Stripe token more than once: tok_CWdiwIchZfRjEK.
     # ./app/services/payment_processing_service.rb:267:in `rescue in charge_stripe'
     # ./app/services/payment_processing_service.rb:209:in `charge_stripe'
     # ./app/services/payment_processing_service.rb:79:in `charge_card_internal'
     # ./app/services/payment_processing_service.rb:418:in `capture_charge_stripe'
     # ./app/services/payment_processing_service.rb:385:in `capture_charge_internal'
     # ./app/services/payment_processing_service.rb:35:in `capture_charge'
     # ./spec/services/payment_processing_service_spec.rb:229:in `block (4 levels) in <top (required)>'
     # /Users/kurtis.rainboltgreene/.rvm/gems/ruby-2.4.3@sneakers/gems/vcr-4.0.0/lib/vcr/util/variable_args_block_caller.rb:9:in `call_block'
     # /Users/kurtis.rainboltgreene/.rvm/gems/ruby-2.4.3@sneakers/gems/vcr-4.0.0/lib/vcr.rb:188:in `use_cassette'
     # ./spec/rails_helper.rb:120:in `block (2 levels) in <top (required)>'
     # ./spec/rails_helper.rb:106:in `block (2 levels) in <top (required)>'
     # /Users/kurtis.rainboltgreene/.rvm/gems/ruby-2.4.3@sneakers/gems/rspec-retry-0.5.6/lib/rspec/retry.rb:115:in `block in run'
     # /Users/kurtis.rainboltgreene/.rvm/gems/ruby-2.4.3@sneakers/gems/rspec-retry-0.5.6/lib/rspec/retry.rb:104:in `loop'
     # /Users/kurtis.rainboltgreene/.rvm/gems/ruby-2.4.3@sneakers/gems/rspec-retry-0.5.6/lib/rspec/retry.rb:104:in `run'
     # /Users/kurtis.rainboltgreene/.rvm/gems/ruby-2.4.3@sneakers/gems/rspec-retry-0.5.6/lib/rspec_ext/rspec_ext.rb:12:in `run_with_retry'
     # /Users/kurtis.rainboltgreene/.rvm/gems/ruby-2.4.3@sneakers/gems/rspec-retry-0.5.6/lib/rspec/retry.rb:33:in `block (2 levels) in setup'
     # ------------------
     # --- Caused by: ---
     # Faraday::ClientError:
     #   the server responded with status 400
     #   /Users/kurtis.rainboltgreene/.rvm/gems/ruby-2.4.3@sneakers/gems/faraday-0.13.1/lib/faraday/response/raise_error.rb:13:in `on_complete'

Finished in 10.22 seconds (files took 19.85 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/services/payment_processing_service_spec.rb:222 # PaymentProcessingService.capture_charge stripe should work if authorization expired/has been refunded

Now, I have no idea why this happens, but I have all the time in the world to figure it out.

Why is LICENSE.md executable?

executable file
https://github.com/rspec/rspec/blob/e1c2c6bd78c849d7956431331f32ba5092951dab/LICENSE.md

Could you please remove the executable bit?

Why no one is using the funds in opencollective?

Hello,
I'm looking for projects to sponsor on OpenCollective for my employer and we use rspec a lot.

I checked the opencollective page and seems like there's about 5000 usds collected but no one has ever used it.
Is there any plans for it? Because we'd rather help a project that actually uses the funds to improve the library.

[HELP] Filter warnings

Is there a way to filter warnings from specific rubygems? I see you can filter them for backtraces, but it doesn't seem to apply to warnings.

The problem is that there are too many 3rd party libs that I don't have any control over, and they can literally cause Travis to bomb.

RFC: change our Ruby version support policy for RSpec 4

TL;DR

I propose that we change our Ruby version support policy for RSpec 4 so that dropping support for old ruby versions is no longer coupled to major version releases. Instead, I recommend we adopt a policy based around supporting old Ruby versions for N months after the Ruby core team has EOL'd
it (for some reasonable value of N).

The Current State of Things

We currently support 10 6 versions of MRI:

~~1.8.7~~
~~1.9.2~~
~~1.9.3~~
~~2.0~~
~~2.1~~
~~2.2~~
2.3
2.4
2.5
2.6
2.7
3.0

In addition, we have been strictly interpreting SemVer to mean that the only time we can drop support for an old version of Ruby is when we do a major release. As a result, we drop support for old versions very, very rarely. In fact, in all my years of involvement with RSpec (dating back to 2010), I can only think of one version of Ruby we've ever dropped support for: we stopped supporting 1.8.6 when RSpec 3 was released.

I think the amount of effort we expend supporting old versions vastly exceeds the utility to our users.

Why is this a problem?

Supporting old Ruby versions has a very real maintenance cost:

Supporting old versions bloats our Travis build matrix, costing Travis more resources, and slowing down our feedback cycle from our CI builds.
Our CI build does not consistently pass on old Ruby versions for reasons outside our control. For example, our CI builds get intermittent segfaults on MRI 1.9.2 and REE. Dealing with those failures (kicking the build, etc) has a very real maintenance cost.
Continuing to support old Ruby versions has prevented us from upgrading our dependencies. For example, we are still on Cucumber 1.x, even though Cucumber ~~3.1~~ 5.2 is out. Cucumber does not support ruby 1.8.7 starting with Cucumber 2, so we haven't been able to upgrade. Staying on old versions of dependencies causes us to accumulate excess tech debt.
In my experience, there's often extra work to get my PRs green against the old Ruby versions. For example, I often accidentally use the newer hash syntax, which 1.8.7 cannot parse. After the CI build finishes, I see the failure, fix it, and force push to address the issue. This creates extra work for what should be simple changes.
Supporting old Ruby versions limits our ability to take advantage of new Ruby features.

Regarding SemVer

The SemVer spec does not specifically document when a library is allowed to drop support for an old version of a language. I'd argue that it's a grey area that we're allowed to decide on for our project. And even if it did explicitly document it, it's up to us to decide if we want to strictly follow it. IMO, the important thing about SemVer is that your project documents the semantics of your versioning and sticks to it--not necessarily that you follow the SemVer spec. IMO, if we realize that strict adherence to the SemVer spec was inhibiting our ability to serve our users due to extra work it requires, it would be wise and appropriate to choose not to follow the spec anymore, and decide on our own semantic that we think better serves our users.

That said, I don't believe the SemVer spec requires that we maintain support for old versions of the language until the next major release.

Coupling Version Drops to Major Releases is a problem

While we strive to follow SemVer, bumping RSpec's major version is not purely a technical decision. It's also a marketing decision. The Ruby community has certain expectations around a major release of a project like RSpec containing major new features. In addition, there are lots of published materials (such as my own book) that reference RSpec's version number.

That means that we can't simply rev the major version number more often, as a means to drop old ruby versions. Besides, I think our users appreciate the stability of a major RSpec version line lasting for years.

Given that major new RSpec versions have historically only happened every 3-5 years, and our recent productivity is, if anything, less than it's been in the past, I think that coupling Ruby version support to major releases is problematic. We could better serve our users (by more productively addressing their issues, building new features, etc) if we were able to drop support for old versions of Ruby between major versions.

So, I believe that beginning with RSpec 4, we should come up with a new Ruby version policy that is not coupled to major releases.

What should we do instead?

I propose that we allow ourselves to drop support for old versions of Ruby as part of a minor release (e.g. x.y.0) in addition to major releases. In addition, I think it would be beneficial to have a specific policy about when we will drop old versions, so that it's not arbitrary based on when we feel like it. The Ruby core team announces the support schedule for each version of Ruby, and that includes an EOL date. I think we should adopt a policy of dropping support for old versions of ruby in the next minor release that comes N months after a version is EOL'd (for some reasonable value of N, such as 6, 12, 18 or 24).

Here's a concrete example. Ruby 2.0 was EOL'd on 2016-02-24. If we had adopted this policy for RSpec 3, and chose N=24, we would be dropping support for Ruby 2.0 in RSpec 3.8, which is the next minor release, since 2 years has elapsed since it was EOL'd.

How would this effect users?

For users who use RSpec to test applications: I do not expect this to have much effect (if any) on these users. This could really only effect users who are running really old versions of Ruby that are months or years past the point where the Ruby core team is supporting it. I doubt there are any users who are allowing their Ruby version to remain so far behind while also staying on the latest version of RSpec.
For users who use RSpec to test gems: users who support old versions of Ruby that we no longer support will be effected. They won't be able to upgrade RSpec without dropping support for old ruby versions. However, if we pick a large enough value of N, the number of users who are effected by this should be small.

Questions

Thoughts on the idea as a whole?
If we went with this proposal, what value of N should we pick?

Nested Before/Around Run In Weird Order

If you have a describe block with an before(:each) and then nest a describe block with an around(:each) the around(:each) runs before the before(:each). I would have thought the around(:each) is just a nice way of writing before(:each) after(:each) and sharing some state between them. but because of the way around(:each) always runs before before(:each) even if it is nested lower it makes around(:each) much less useful.

there doesn't seem to be a test case for this behaviour in the documentation so I'm not sure if this was deliberate or not. though, i guess it would be hard to change this behaviour because probably a lot of people rely on it.

https://relishapp.com/rspec/rspec-core/v/2-0/docs/hooks/around-hooks#before/after(:each)-hooks-are-wrapped-by-the-around-hook

describe "filter" do

  before(:each) do
    puts "before each outer"
  end

  describe "inner" do
    around(:each) do |example|
      puts "around each inner"
      example.run
    end

    it "should" do
      puts "example"
    end
  end

end

actual:

around each inner
before each outer
example

expected:

before each outer
around each inner
example

here is how it works if they are both before(:each) rather than using an around(:each) for the inner.

describe "filter" do

  before(:each) do
    puts "before each outer"
  end

  describe "inner" do
    before(:each) do
      puts "before each inner"
    end

    it "should" do
      puts "example"
    end
  end

end

before each outer
before each inner
example

RSpec 4 plan

It's been in the air and mostly in sparse @JonRowe's comments (1, 2). This is an attempt to gather the ideas and start the discussion.

Release step-by-step plan

pre-4.0:

fix internal deprecation matchers rspec/rspec-support#451
add deprecations for what we end up removing in 4.0
- implicit block syntax (rspec/rspec-expectations#1139, rspec/rspec-core#2800)
- rspec/rspec-core#2880
- should (monkey and non-monkey), syntax config options
- globally-exposed DSL, and its config option
- shared_context_metadata_behavior (discussion in rspec/rspec-core#2832)
- run_all_when_everything_filtered
- ... a couple others
- rspec/rspec-mocks#1418
- should Mocks syntax
- allow_message_expectations_on_nil example method
- rspec/rspec-expectations#1301
- operator matching (is_expected.to be is a replacement for should, not just is_expected.to)
- legacy matcher support
- include_chain_clauses_in_custom_matcher_descriptions
- present tense predicates
- ~~[ ] deprecate currently_executing_a_context_hook and recommend using current_scope instead (rspec/rspec-core#2895)~~
- ~~[ ] ? AnyInstance~~
- ~~[ ] ? DRb~~

4.0.0:

post-4.0

Ruby support

EOL Ruby means we support 2.5+, since 2.4 is EOL in April 2020
However, according to 2020 RoR community survey

70% use 2.5+
81% use 2.4+
89% use 2.3+

Do 2.3 and 2.4 cause any trouble? I could only find this:

        # 2.4 has improved BigDecimal formatting so we do not need
        # to provide our own.
        # https://github.com/ruby/bigdecimal/pull/42
        classes.delete(BigDecimalInspector) if RUBY_VERSION >= '2.4'

I can only think of RuboCop's TargetRubyVersion setting that has a minimum of 2.4. That means we won't be able to run rubocop on 2.3 CI build.

More on this in https://github.com/rspec/rspec/issues/25

Remove deprecated features/Introduce new defaults

shared_context_metadata_behavior
monkey-patching mode
should syntax (with implicit receiver only, where should can be backed by is_expected.to. extract to a gem?)
implicit block syntax (deprecated in rspec/rspec-expectations#1139)

Consider deprecating long-hanging/obscure features

~~[ ] DRb runner. I only know of Spork that was using it, but its 2.0.0-rc is years old now with no signs of life~~

Cleanup

kwargs delegation

APPLICATION ERROR 🔴🔴🔴❗❗❗❗

GEM PAGE documentation isuue

Page is not visible on gem docs

Rspec fails to stub with allow or allow_any_instance_of with stacked before blocks

Rspec version 3.5.4

I have a controller test with code like this:

RSpec.describe MyController, type: :controller do
  before do
    allow(ServiceKlass1).to receive(:method1)
  end

  describe "GET #index" do

    before do
      allow_any_instance_of(ServiceKlass2).to receive(:method2).and_raise(StandardError)
    end

    it 'reports to new relic' do
      expect(controller).to receive(:report_to_new_relic)
      get :index
    end

  end
end

MyController runs both ServiceKlass1 and ServiceKlass2 , functions method1 and method2.

The stub that occurs within the nested before block (which stubs the method profile and raises a StandardError) does not working once get :index runs. I'm not sure if this is intended behavior. If I add a byebug before the get :index statement, I can show that my ServiceKlass2 (which is run by my controller) raises a StandardError, but does not actually raise a StandardError when get :index is run.

Suggestion: Warn / opt-in for remote database

Hi folks!

We just ran into a hiccup during our normal course of dev.

We accidentally had our environment set to production, with all production env vars active locally. Then, we ran our tests.

(Imagine the hilarity and sadness that ensued.)

We didn't know what happened for a few hours. All of this to say - perhaps it's a useful idea to have RSpec provide a warning or require explicit opt-in when being run in production environments, and/or when connecting to a remote data source? This may help others avoid mass deletion of data. (Of course, we have a backup, but not everyone will have an up-to-date backup.)

Yes, this is something we should be responsible for - but it seems like an overly powerful command to run a test suite and accidentally totally destroy a production database.

Note - I apologize if there is already a blocking/safety feature like this, or a previous thread addressing the issue; I couldn't find one in my cursory search. Thanks!

Add support for notify_expectation_failures option to match_when_negated

Unlike match, the match_when_negated function does not support the notify_expectation_failures option. As a result, any expectation inside the failure is reported as a failure of the outer expectation instead of providing the detail of the expectation that actually failed.

rspec / rspec-metagem Goto Github PK

rspec-metagem's People

Contributors

Stargazers

Watchers

Forkers

rspec-metagem's Issues

TL;DR

The Current State of Things

Why is this a problem?

Regarding SemVer

Coupling Version Drops to Major Releases is a problem

What should we do instead?

How would this effect users?

Questions

Ruby support

Remove deprecated features/Introduce new defaults

Consider deprecating long-hanging/obscure features

Cleanup

kwargs delegation

GEM PAGE documentation isuue

Recommend Projects

Recommend Topics

Recommend Org