Cassette regeneration about dropbox_api

[Jesus]

I've added documentation on how to regenerate any cassette: https://github.com/Jesus/dropbox_api#testing

We only have procedures to regenerate the cassettes for get_metadata and list_folder, the others will be implemented as they're needed. I don't think there's need to build them all at once.

I think we can close this ticket now as your issue with the content_hash attribute was also resolved. If I've missed anything please re-open.

[Jesus]

I'm sorry, the files aren't available anywhere, and the cassettes aren't easy to regenerate because the state of the Dropbox account changes after collecting new recordings.

For example, if I run dropbox.delete("file.txt") and record the result on a cassette, I would need to upload file.txt again in order to record the same cassette again. So I normally just get one real recording from Dropbox and work from there.

This is a real problem when it comes to test this library.

Ideally, we would have an automatic way to set up the required files in the test Dropbox account. Unfortunately, this isn't an option with the current code. The only reason why I didn't do this from the beginning is because I didn't have a way to do this automatically (for example, the upload endpoint wasn't available), now it's a good time to do it.

As a workaround until we have a better way to set up the test account, I can suggest some different solutions:

• Manually upload the files to the Dropbox account.
• Manually update the existing VCR cassettes to mimic the response you know Dropbox should respond. Take care with care.

[wouter]

Thanks for the comment Jesus. I will take a look at your two options and see if I can find an easy way for this. I agree that the way you describe would be a better way (using the upload endpoint to restore original state), but that would indeed require some work. Perhaps split it off in another issue?

[Jesus]

I've started working on a solution to the testing problem.

I think you can already start using what I just did. I think you just need to regenerate the cassettes for get_metadata, you can regenerate those cassettes with a few rake tasks.

1. Manually delete the existing cassettes in spec/fixtures/vcr_cassettes/get_metadata.
2. Run DROPBOX_OAUTH_BEARER=YOUR_AUTH_BEARER rake test:build_scaffold:get_metadata.
3. Run DROPBOX_OAUTH_BEARER=YOUR_AUTH_BEARER rspec spec/endpoints/files/get_metadata_spec.rb. After this, the cassettes will be written already, but your token is embed on it.
4. You need to remove your auth bearer from the cassettes before doing the commit. There's also a rake task to help on that: rake test:vcr:mock_authorization_bearer

I reckon this is still a lot of manual work, but it's just a start and it will let you continue work for now.

[wouter]

Great! This scaffolding worked for me, after a small adjustment (see #16).

Unfortunately, it seems my original problem still exists. If I add the content_hash field, all the cassettes need to be regenerated, because the content_hash field can't be populated with the old cassettes that do not contain this value yet. This might require some more scaffolding.

[Jesus]

Are you saying that you need to regenerate the cassettes for all existing endpoints?

If that's the case I'm afraid it's going to take a while before I write scaffoldings for all of them...

Looks like all you wanted was to add support for the new content_hash attribute. If you want, you can open a PR with whatever progress you've done already. From there, we can work together to finish this particular request more quickly.