Google-api-ruby-client: Testing tools?

Created on 3 Dec 2013  路  4Comments  路  Source: googleapis/google-api-ruby-client

Are there any testing tools included with this library? I'd like to test my application code without making actual requests to Google; the only way I can think of doing this is to use webmock to mock out requests that Google Api Client makes.

triage me

Most helpful comment

A coworker reached out to me about this today, so I'm commenting and closing out this issue. It's been over a year since I last worked with this library, but I have some suggestions--keep in mind they're just my opinion.

For any methods provided by the GoogleApiRubyClient gem that you'll be consuming, I recommend writing your own wrapper methods so that you can mock out this library's behavior. Use this strategy for most of your application unit and integration testing.

Benefits:

  • faster test suite, with a focus on testing your own code
  • ease of upgrading (eventually), i.e. I began using this library to transition from using the Youtube V2 API to the Youtube V3 API for fetching user video data
  • Mocking your wrapper methods will work more cleanly with verifying doubles (Rspec-fire, Rspec 3). This tool generates Ruby methods based on the API endpoints available, similar to what a SOAP client does with a WSDL document, so methods you're using may not be available without talking to Google (or loading a cached API spec).

Write a small subset of your tests to make calls to Google. Set up test accounts as necessary for this. Use a tool like VCR to capture and refresh your API fixtures on a regular basis (i.e. monthly, every 3 months, etc).

Benefits:

  • Making sure the API hasn't changed on you. In my original use case, the code connected to the Youtube Data V2 and Youtube Analytics APIs. These seemed relatively stable, but this is a multi-purpose gem used for connecting to many APIs, so use your discretion in how thoroughly you write these tests.
  • A few in your test suite provide confidence that your full stack works together, and continues to work with the outside world over time.

Drawbacks:

  • These tests will be slow because they're making network calls. You'll get false-positives with network outages.
  • More complexity, higher effort. Getting the details right for account authentication will be a pain.

Don't treat any of this as gospel. If the suggestions above don't make sense to you, don't use them. Go out and build stuff :)

All 4 comments

:+1: Same here

Any suggestions for this? I would find advice on this very helpful.

A coworker reached out to me about this today, so I'm commenting and closing out this issue. It's been over a year since I last worked with this library, but I have some suggestions--keep in mind they're just my opinion.

For any methods provided by the GoogleApiRubyClient gem that you'll be consuming, I recommend writing your own wrapper methods so that you can mock out this library's behavior. Use this strategy for most of your application unit and integration testing.

Benefits:

  • faster test suite, with a focus on testing your own code
  • ease of upgrading (eventually), i.e. I began using this library to transition from using the Youtube V2 API to the Youtube V3 API for fetching user video data
  • Mocking your wrapper methods will work more cleanly with verifying doubles (Rspec-fire, Rspec 3). This tool generates Ruby methods based on the API endpoints available, similar to what a SOAP client does with a WSDL document, so methods you're using may not be available without talking to Google (or loading a cached API spec).

Write a small subset of your tests to make calls to Google. Set up test accounts as necessary for this. Use a tool like VCR to capture and refresh your API fixtures on a regular basis (i.e. monthly, every 3 months, etc).

Benefits:

  • Making sure the API hasn't changed on you. In my original use case, the code connected to the Youtube Data V2 and Youtube Analytics APIs. These seemed relatively stable, but this is a multi-purpose gem used for connecting to many APIs, so use your discretion in how thoroughly you write these tests.
  • A few in your test suite provide confidence that your full stack works together, and continues to work with the outside world over time.

Drawbacks:

  • These tests will be slow because they're making network calls. You'll get false-positives with network outages.
  • More complexity, higher effort. Getting the details right for account authentication will be a pain.

Don't treat any of this as gospel. If the suggestions above don't make sense to you, don't use them. Go out and build stuff :)

In addition you can generate google api model objects:
person = Google::Apis::PeopleV1::Person::Representation.new(Google::Apis::PeopleV1::Person.new).from_json(body, unwrap: Google::Apis::PeopleV1::Person)
where body is json string like this:
{ "resourceName": "people/114528407945569518008", "etag": "%EgoBAj0DCAk+CjcuGgwBAgMEBQYHCAkKCwwiDFVjcjlBeHF==", "names": [ { "metadata": { "primary": true, "source": { "type": "PROFILE", "id": "114528407945569518" } }, "displayName": "Test Testov", "familyName": "Testov", "givenName": "Test", "displayNameLastFirst": "Testov, Test" } ] }

You can create some json files with test data, load them with File.read and test your business logic

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jiggneshhgohel picture jiggneshhgohel  路  6Comments

martincalvert picture martincalvert  路  4Comments

davidraj picture davidraj  路  6Comments

olegpanchenko picture olegpanchenko  路  3Comments

a14m picture a14m  路  7Comments