
Security News
Follow-up and Clarification on Recent Malicious Ruby Gems Campaign
A clarification on our recent research investigating 60 malicious Ruby gems.
This gem allows you to write mock expectations in an AAA (Arrange-Act-Assert) fashion
with RSpec::Mocks. It does this by allowing you to declare examples with :spy => true
or :spy
(if you use config.treat_symbols_as_metadata_keys_with_true_values = true
)
so that they are effectively executed before everything else. Here's a simple example:
describe "Example" do
let(:collaborator) { stub.as_null_object }
before do
collaborator.message
end
it "should receive a message", :spy => true do
collaborator.should_have_received :message
end
it "should not receive other_message", :spy => true do
collaborator.should_not_have_received :other_message
end
end
Add this line to your application's Gemfile in the :test
group
gem 'rspec-spy'
And then execute:
$ bundle
Or install it yourself as:
$ gem install rspec-spy
Add to your spec_helper.rb in RSpec.configure
AFTER any other global before hooks, especially DatabaseCleaner:
# any config.before hooks should go above
require 'rspec-spy'
config.before(:each, :spy => true) do |example|
RSpec::Spy(example)
end
Just tag your examples with :spy => true
or :spy
(if you use
config.treat_symbols_as_metadata_keys_with_true_values = true
)
You should be able to use all of the functionality from rspec-mocks that you're
used to, including spying on class methods.
it "should receive message", :spy => true do
collaborator.should_have_received :message
end
# with config.treat_symbols_as_metadata_keys_with_true_values = true
it "should receive message", :spy do
collaborator.should_have_received :message
end
let
, it gets confusing because you cannot set them
in before
blocks and use them in spy
blocks. Remember, spy
blocks actually happen before
before
blocks. Example (see the example at the beginning of the readme for the right way):describe "what not to do" do
before do
@collaborator = stub.as_null_object
@collaborator.message
end
# These will fail because @collaborator is nil because this happens
# before the above before block
it "should receive a message", :spy => true do
@collaborator.should_have_received :message
end
it "should not receive other_message", :spy => true do
@collaborator.should_not_have_received :other_message
end
end
and_return
in your spy
block and if you have normal examples you'll also
need to stub
it. Yes, this is annoying, but that's how rspec-mocks works and it's one
of the many reasons you shoudln't mock when the return value matters (just stub
). Example:describe "stubbing and mocking at the same time" do
let(:collaborator) { stub.as_null_object }
before do
collaborator.stub(:message) { 5 }
@result = collaborator.message
# This will fail unless you use and_return
@result.should == 5
end
it "should return 5" do
# This will fail unless you stub in before
@result.should == 5
end
it "should receive a message", :spy => true do
collaborator.should_have_received(:message).and_return(5)
end
end
git checkout -b my-new-feature
)git commit -am 'Added some feature'
)git push origin my-new-feature
)FAQs
Unknown package
We found that rspec-spy demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
A clarification on our recent research investigating 60 malicious Ruby gems.
Security News
ESLint now supports parallel linting with a new --concurrency flag, delivering major speed gains and closing a 10-year-old feature request.
Research
/Security News
A malicious Go module posing as an SSH brute forcer exfiltrates stolen credentials to a Telegram bot controlled by a Russian-speaking threat actor.