Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

stub_requests

Package Overview
Dependencies
Maintainers
1
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

stub_requests

  • 0.1.11
  • Rubygems
  • Socket score

Version published
Maintainers
1
Created
Source

StubRequests

Badges

Build Status Maintainability Test Coverage

This gem attempts to solve a problem I've had for the time with WebMock.

When something changes, I have to update every single stub_request.

This gem allows me to only update the crucial parts while abstracting away things like service URI's, endpoint definitions and focus on the important things.

This is achieve by keeping a registry over the service endpoints.

Required ruby version

Ruby version >= 2.3

Installation

Add this line to your application's Gemfile:

gem "stub_requests"

And then execute:

bundle

Or install it yourself as:

gem install stub_requests

Usage

To use the gem we need to register some service endpoints. In the following example we are connecting to a rails inspired service.

The naming of the service_id and endpoint_id's is irrelevant. This is just how we look things up in the registry.

Register service endpoints

StubRequests.register_service(:google_ads, "https://api.google.com/v5") do
  get    "ads",     as: :ads_index
  get    "ads/:id", as: :ads_show
  patch  "ads/:id", as: :ads_update
  put    "ads/:id", as: :ads_update
  post   "ads",     as: :ads_create
  delete "ads/:id", as: :ads_destroy
end

Now we have a list of endpoints we can stub.

Stubbing service endpoints

StubRequests.stub_endpoint(:ads_index)
            .to_return(code: 204, body: "")

# This is the equivalent of doing the following in WebMock
Settings.google_ads_base_uri = "https://api.google.com/v5"

WebMock.stub_request(:get, "#{Settings.google_ads_base_uri}/ads")
       .to_return(status: 204, body: "")
StubRequests.stub_endpoint(:ads_update, id: 1) do
  with(body: request_body.to_json)
  to_return(code: 200, body: response_body.to_json)
end

# This is the equivalent of doing the following in WebMock
Settings.google_ads_base_uri = "https://api.google.com/v5"

WebMock.stub_request(:patch, "#{Settings.google_ads_base_uri}/ads/#{id}")
       .with(body: request_body.to_json)
       .to_return(status: 200, body: response_body.to_json)

This reduces the need to spread out URI's in the test suite without having to resort to shared examples.

Metrics

Metrics collection are by default turned off. It can be turned on by the following code.

StubRequests.configure do |config|
  config.record_stubs = true
end

Endpoint invocation callbacks

# To jump into pry when a request is called
callback = lambda do |request|
  p request
  binding.pry
end

callback = ->(request) { p request; binding.pry }

StubRequests.register_callback(:document_service, :show, :get, callback)
# To unsubscribe from notifications
StubRequests.unregister_callback(:document_service, :show, :get)

Using Method Stubs

#
# 1. Register some service endpoints
#
StubRequests.register_service(:documents, "https://company.com/api/v1") do
  get    "documents/:id", as: :documents_show
  get    "documents",     as: :documents_index
  post   "documents",     as: :documents_create
  patch  "documents/:id", as: :documents_update
  put    "documents/:id", as: :document_put
  delete "documents/:id", as: :documents_destroy
end

#
# 2. Create a module where the methods should be defined
#
module Stubs::Documents; end

#
# 3. Define the stubs for the registered endpoints
#
StubRequests::DSL.define_stubs(:documents, Stubs::Documents)

Documents.instance_methods #=>
  [
    :stub_documents_show,
    :stub_documents_index,
    :stub_documents_create,
    :stub_documents_update,
    :stub_document_put,
    :stub_documents_destroy,
  ]

#
# 4. Use the module in our tests
#
RSpec.describe ClassThatCallsTheDocumentService do
  include Stubs::Documents

  let(:document_id) { 123455 }
  let(:documents_show_body) do
    {
      id: document_id,
      status: "draft",
    }
  end

  before do
    stub_documents_show(id: document_id)
      .to_return(status: 200, body: documents_show_body.to_json)
  end

  it "stubs the request nicely" do
    # execute code that calls the service
    uri      = URI("https://company.com/api/v1/documents/#{document_id}")
    response = Net::HTTP.get(uri)

    expect(response).to be_json_eql(example_api_list_task_response.to_json)
  end
end

If you prefer to keep a hard copy of the methods in your project then you can print the method definitions to the console and copy paste.

This puts the user in charge of keeping them up to date with the gem.

#
# 1. Register some service endpoints
#
StubRequests.register_service(:documents, "https://company.com/api/v1") do
  get    "documents/:id", as: :documents_show
  get    "documents",     as: :documents_index
  post   "documents",     as: :documents_create
  patch  "documents/:id", as: :documents_update
  put    "documents/:id", as: :document_put
  delete "documents/:id", as: :documents_destroy
end

#
# 2. Print the stub definitions to STDOUT
#
StubRequests.print_stubs(:documents)

#
# 3. Copy the stubs into a module
#
module DocumentStubs
  def stub_documents_show(id:, &block)
    StubRequests.stub_endpoint(:documents_show, id: id, &block)
  end


  def stub_documents_index(&block)
    StubRequests.stub_endpoint(:documents_index, &block)
  end


  def stub_documents_create(&block)
    StubRequests.stub_endpoint(:documents_create, &block)
  end


  def stub_documents_update(id:, &block)
    StubRequests.stub_endpoint(:documents_update, id: id, &block)
  end


  def stub_document_put(id:, &block)
    StubRequests.stub_endpoint(:document_put, id: id, &block)
  end


  def stub_documents_destroy(id:, &block)
    StubRequests.stub_endpoint(:documents_destroy, id: id, &block)
  end
end

Future Improvements

API Client Gem

Since we have a service + endpoint registry, I was thinking it might make sense to make this into an API client. Not sure yet, maybe this will become multiple gems in the future so that someone can pick and choose.

Anyway, the idea was to provide endpoint calls in production and stubbed requests in tests using the same registry.

Development

After checking out the repo, run bin/setup to install dependencies.

Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to rubygems.org.

Contributing

Bug reports and pull requests are welcome on GitHub at: issues.

This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.

License

The gem is available as open source under the terms of the MIT License.

Code of Conduct

Everyone interacting in the StubRequests project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.

FAQs

Package last updated on 08 Feb 2019

Did you know?

Socket

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.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc