Stubbing out authentication

I have the gcloud module talking to a local cloud datastore using the gcd tool for automated testing but am finding that it only works if I provide real credentials from my google console. Is there a way to stub out the authentication process so I can use test credentials?

This should definitely be possible. Can you show me how you're getting the Dataset instance and the errors/signs that it's not working that you are getting?

I put together a test branch, please give it a shot and let me know how it goes!

$ npm install --save stephenplusplus/gcloud-node#spp--gcd-no-auth

Thanks for the response. I'll give that branch a go tomorrow. So far I've just set the DATASTORE_HOST environment variable to my gcd server as I haven't come across any specific instructions for stubbing out the oAuth call that is made with the credentials.

I get an invalid_grant response out of the gcloud lib when calling dataset.save

So far I've just set the DATASTORE_HOST environment variable

That's mainly what I was wondering. Our code currently isn't seeing that and turning off the auth step. Hopefully that branch resolves that.

Looks like this may now be turning off the auth step but breaking something else further down the line as when it comes to doing the save I get [Error: Invalid URI "undefined/datastore/v1beta2/datasets/suppliers/commit"]

I found that this.apiEndpoint from the Dataset constructor needs to be set for the API calls. Seems fairly easy to fix but can't quite see, at the moment, how to write tests to ensure that both this.apiEndpoint and customEndpoint both get set correctly.

Oops, good catch. I just pushed a fix (hopefully).

If this works, I'll probably re-think how this is written before sending a PR. It's getting a wee bit messy.

Yep that change seems to have done the trick.

These are my thoughts on the tests/implementation (slightly naive perhaps given I don't know any of the rest of the code base), hope they're welcome 😄 ...

I thought that with the current implementation the tests would be better just asserting that ds.apiEndpoint is set to the correct URL depending on the options/env, rather than testing the implementation of that private determineApiEndpoint_ function. And if determineApiEndpoint_ became just getCustomEndpoint then you shouldn't need to mutate the options parameter as a side effect. I did feel it also needs a test that when a custom endpoint is provided then it sets up the auth correctly as presumably that's why this slipped through the net. That was the main thing I couldn't work out how to do given the current state of things, so I guess you may want to tweak things further.

Anyway. Thanks for your help! Can live with it making the live auth calls for the time being until you figure something out.

Of course, all thoughts are welcome. I will ping you when it's in the PR
stage for more :)

On Wednesday, November 11, 2015, Chris Impey [email protected]
wrote:

Yep that change seems to have done the trick.

These are my thoughts on the tests/implementation (slightly naive perhaps
given I don't know any of the rest of the code base), hope they're welcome [image:
😄] ...

I thought that with the current implementation the tests would be better
just asserting that ds.apiEndpoint is set to the correct URL depending on
the options/env, rather than testing the implementation of that private
determineApiEndpoint_ function. And if determineApiEndpoint_ became just
getCustomEndpoint then you shouldn't need to mutate the options parameter
as a side effect. I did feel it also needs a test that when a custom
endpoint is provided then it sets up the auth correctly as presumably
that's why this slipped through the net. That was the main thing I couldn't
work out how to do given the current state of things, so I guess you may
want to tweak things further.

Anyway. Thanks for your help! Can live with it making the live auth calls
for the time being until you figure something out.

—
Reply to this email directly or view it on GitHub
#936 (comment)
.

Good work 👍

When might this make it to npm?

I'll shoot for Wednesday/Thursday next week. Our code is in a bit of a transition state right now, we have a few more PRs to squeeze in. Will ping you when it's out!

chore: update v2.14.2 gapic-generator-typescript (#936)