Prefer not using hanging indents - see #7 under Style&Linting.

Fixed. Have we considered using yapf or another opinionated formatter that will make these decisions automatically?

Java has something like this (google-java-formatter), but I'm not aware of plans for Python. I'm okay with it as long as it's compatible with the google python style guides.

It is a google project so I would assume it should be? :) I can run it by others on the team who are opinionated about python stuff.

This language was taken from the canonical sample, see https://github.com/googleapis/nodejs-storage/blob/master/samples/hmacKeyCreate.js#L48 . I would think that consistency is most important, unless we want to change it in all of them?

I'll leave the final decision up to @frankyn, but my concerns are that:

1. It's currently improper english, which might make it harder for non-native english speakers to understand
2. Saying "there is no API to recover it" seems to imply that there may be some other way to recover it, like a support ticket or something (which I assume it not the case)

This fixture is inconsistently handling fixtures - sometimes it uses the snippet to perform the action and sometimes not. We should be consistent.

I think it makes more sense to avoid using the snippet, so that we don't have to worry about the logs from another snippet inadvertently showing up in the test or logs somewhere.

I thought about this a bit-- the downside of not using the snippet is that then it's difficult to test the create_key snippet (because then I can't leverage the teardown in the fixture for the newly created key, so if assertions in the test fail the key will never be deleted). Any thoughts on how to get around this?

I think you have a couple of options:

• For testing the create_key snippet, you could call create, then delete, then assert the output of create.
• You could reset capsys at the start of the function by calling readouterr()
• If you switch capsys to the last parameter, it'll create the other fixtures before setting up the stdout capture (so you can use snippets without effecting the results of the test)

I think the first is probably preferable, as it leaves cleaner logs and having an explicit test for create_key is a better indicator the problem is in the creation, rather than an error in a fixture bubbling up in a different test.

Good points, thanks for the advice. I'll take your first suggestion.

We probably want to make this it's own fixture and scope it to module to avoiding initializing a new one every time.

Are you referring specifically to storage_client? I could do this, but I guess I wasn't thinking of it as a resource that is expensive to initialize.

Other tests such as https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/storage/cloud-client/acl_test.py and https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/storage/cloud-client/bucket_policy_only_test.py seem to use a similar approach with including storage.client in one function-level fixture.

Yeah - some of our clients launch threads and tie up other resources (which is why I asked about close() elsewhere). This client doesn't look too heavy, but there are a couple of network calls for oath and an http session being created, so it's probably worthwhile to reuse.

I'm actually not sure if you can nest fixtures, but if it doesn't work and since you don't have to close it, you can probably just move it to a module level variable.

You can nest fixtures, but I decided to go for the module-level variable because it seems pretty safe and it's less confusing to read.

I think you have a couple of options:

• For testing the create_key snippet, you could call create, then delete, then assert the output of create.
• You could reset capsys at the start of the function by calling readouterr()
• If you switch capsys to the last parameter, it'll create the other fixtures before setting up the stdout capture (so you can use snippets without effecting the results of the test)

I think the first is probably preferable, as it leaves cleaner logs and having an explicit test for create_key is a better indicator the problem is in the creation, rather than an error in a fixture bubbling up in a different test.

Yeah - some of our clients launch threads and tie up other resources (which is why I asked about close() elsewhere). This client doesn't look too heavy, but there are a couple of network calls for oath and an http session being created, so it's probably worthwhile to reuse.

I'm actually not sure if you can nest fixtures, but if it doesn't work and since you don't have to close it, you can probably just move it to a module level variable.