Skip to content
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

prepare remote state via rake task #14

Open
wenzowski opened this issue Nov 6, 2012 · 4 comments
Open

prepare remote state via rake task #14

wenzowski opened this issue Nov 6, 2012 · 4 comments

Comments

@wenzowski
Copy link
Contributor

Per #11, we agree creating buckets manually sucks.

Writing tests for this api is tricky because buckets belong to a global namespace, but permission to modify them is assigned per project / per user.

We must assume that not every person checking out this repo will have access to the project containing the buckets named in the test suite. Therefore, the test suite should be able to generate a new set of bucket names on demand, and should be able to automatically recreate the expected remote state.

Auto-generating UUIDs as bucket names seems like an obvious solution to reduce the risk of namespace conflicts to near zero.

I propose that, once generated, all per-user bucket names should be stored in a .gitignore'd spec/support/buckets.yml and a spec/support/buckets.yml.example should be provided as a fallback to run the suite using provided vcr recordings.

It seems to me that the most straightforward way to generate this config file is via rake task.

Some important test suite options should probably be set based on the presence of this file, such as automatic-re-recording (eg. re_record_interval: 1.hour).

This could also allow bucket names to be removed from the default recordings via dynamic-erb-cassettes.

@wenzowski
Copy link
Contributor Author

per #11, we agree that re-recording should just work.

Since the whole point of the test suite is to determine that the current version of the gem correctly modifies remote state using the api, I don't see how we can reliably expect the current version of the gem to recreate remote state prior to running the suite. Therefore, I think we should use a known working version of the gem (likely the most recent release).

Since this environment configuration (release gem) would conflict with the test suite requirement (prerelease gem), I'd like to suggest adding a secondary gemfile, for instance Gemfile.known_stable to be installed by developer using bundle install --gemfile Gemfile.known_stable.

We'd then be able to call this api setup and teardown (all contained in this conflicting environment) once before the entire suite runs and once after.

RSpec.configure do |config|
  config.before(:suite) { create_buckets_and_objects_using_latest_stable }
  config.after(:suite) { destroy_all_objects_and_buckets_using_latest_stable }
end

I know it's a little wacky, but what do you think?

@2potatocakes
Copy link
Owner

:) I'm always fine with a little wacky mate. But I don't think there's any need. In the changes I pushed yesterday I rewrote your bucket spec to create and destroy new buckets for every test and also included a couple of new VCR filter procs:

GS_BUCKET_MATCHER = lambda do |request_1, request_2|
  (request_1.uri.to_s.match(/https?:\/\/.*\.storage.googleapis.com\//).length ==
    request_2.uri.to_s.match(/https?:\/\/.*\.storage.googleapis.com\//).length) rescue false
end

GS_QUERY_STRING_MATCHER = lambda do |request_1, request_2|
  request_1.parsed_uri.query == request_2.parsed_uri.query
end

I also had to remove your global VCR wrap from the spec_helper so that the specs can each use their own independent cassettes with their own filters applied to each cassette. Most notibly the "match_requests_on" filter.

The GS_BUCKET_MATCHER is not flawless but it will match the VCR cassettes to the test HTTP requests whenever they're passing requests to ANY bucket URL. ie https://fkdjsflkd-bucket-name-fjdklfj.storage.googleapis.com/ and basically ignore what the bucket name actually is. To make it accurately use the correct VCR cassette though, you need to use it in combination with some of the other predefined VCR filters like this:

use_vcr_cassette "webcfg_exists", :match_requests_on => [:method, GS_BUCKET_MATCHER GS_QUERY_STRING_MATCHER, :body]

I swapped fakeweb over to webmock as well so that we can also use the ":headers" and ":body" filters that webmock allows. Fakeweb, apparently does not support these.

Anyways, out of curiosity. I think what is in trunk at the moment should work for you on your computer using your own credentials as it is at the moment. The only thing you should have to change is the :none to :all on the line:

c.default_cassette_options = { :record => :none } 

If the tests fail on your machine can you please let me know.

Thanks mate.

@wenzowski
Copy link
Contributor Author

trunk working with minor tweaks will submit a PR

@2potatocakes
Copy link
Owner

already done mate sorry, https://travis-ci.org/#!/2potatocakes/google_storage/builds/3091304
I hadn't kicked off my builds earlier properly.

wenzowski pushed a commit to ent-io/google_storage that referenced this issue Nov 7, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants