You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the only way to develop this is by hitting the live Cloud Datastore API. Is there a way we can use these API calls in unit tests without mocking?
Can we have a "local datastore" server that understands the API and makes it easy for local development?
That looks good for local development. It runs on Java right ?
I wonder how difficult it would be to patch in the stubs from AppEngine's dev_appserver.py so that i can use something akin to ext.testbed to unittest locally (ie, without hitting the wire, stay all in Python).
That looks good for local development. It runs on Java right ?
Yes, it is embedding the App Engine Java development server and running the same servlet that is running in production.
I wonder how difficult it would be to patch in the stubs from AppEngine's dev_appserver.py so that i can use something akin to ext.testbed to unittest locally (ie, without hitting the wire, stay all in Python).
You would have to handle the datastore_v1.proto to datastore_v4 convertion somehow.
Keep in mind that datastore_v4private interface is not really documented and also subject to change: datastore_v1 is the public versionned interface.
#130 adds 100% unit test coverage for modules in gcloud, gcloud.datastore. I would call its strategy "stubbing" (testcases explicitly stub out the http or connection objects) rather than "mocking" (using a general-purpose utilitiy like 'mock').
Activity
proppy commentedon Jan 29, 2014
You could use
gcd: the local development server, see:https://developers.google.com/datastore/docs/tools/devserver
jgeewax commentedon Jan 30, 2014
That looks good for local development. It runs on Java right ?
I wonder how difficult it would be to patch in the stubs from AppEngine's dev_appserver.py so that i can use something akin to ext.testbed to unittest locally (ie, without hitting the wire, stay all in Python).
proppy commentedon Jan 30, 2014
Yes, it is embedding the App Engine Java development server and running the same servlet that is running in production.
You would have to handle the
datastore_v1.prototodatastore_v4convertion somehow.Keep in mind that
datastore_v4private interface is not really documented and also subject to change:datastore_v1is the public versionned interface.jgeewax commentedon Jan 30, 2014
Yikes. Well I realllly don't want to force people to spin up a local server in order to run unit tests...
We'll have to come up with a way to stub this out.
tseaver commentedon Sep 23, 2014
#130 adds 100% unit test coverage for modules in gcloud, gcloud.datastore. I would call its strategy "stubbing" (testcases explicitly stub out the http or connection objects) rather than "mocking" (using a general-purpose utilitiy like 'mock').
tseaver commentedon Oct 17, 2014
#106 exists to cover the deficiencies of testing with stubbed / mocked backends.
Spanner p0 system tests (batch #2) (#3604)
Spanner p0 system tests (batch googleapis#2) (googleapis#3604)
Spanner p0 system tests (batch googleapis#2) (googleapis#3604)
Spanner p0 system tests (batch googleapis#2) (googleapis#3604)
Storage: sourceGeneration in copy_blob googleapis#4533 - BugFix googl…
83 remaining items
test: No warnings (#9)
chore: release 0.32.0 (#2)
Chore: Added templated files from Owlbot (#2)
chore: release 1.6.2 (#2)
chore: add split repo templates (#2)
Implement ``Model.query``. (#59)
translator: package to translate dialects
feat(sqlalchemy): implement dialect's minimal functionality (#2)
feat: add types compiler and introspection methods (#2)
feat: add OpenTelemetry Tracing support as a preview feature (#1288)
Spanner p0 system tests (batch #2) (#3604)
chore: release 1.14.0 (#2)
feat: add support for Point In Time Recovery (PITR) (#148)
chore: add python repo templates (#2)
Revert "fix: Update max_instances default to reflect actual value (#2… (