-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
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 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.
I know it's a little wacky, but what do you think? |
:) 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:
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:
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:
If the tests fail on your machine can you please let me know. Thanks mate. |
trunk working with minor tweaks will submit a PR |
already done mate sorry, https://travis-ci.org/#!/2potatocakes/google_storage/builds/3091304 |
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 aspec/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.
The text was updated successfully, but these errors were encountered: