Local unit testing of Datastore

[Anastasios Hatzis]

Hi everyone!

While debugging the datastore behavior for a local unit test, I returned to the docs.

On this page:

https://cloud.google.com/appengine/docs/python/tools/localunittesting

there is a section about testing Datastore, followed by a separate section about testing High Replication Datastore. It was my understanding that HRD is just the old name of the Google Cloud Datastore, but the docs looks as if it were two separate things.

If the consistency policy is the only difference (the code suggests so), I would like to know what's the benefit to test with for example

self.testbed.init_datastore_v3_stub(consistency_policy=datastore_stub_util.PseudoRandomHRConsistencyPolicy(probability=0)

(or 0.5, 1 etc.)

I understand the difference between strong consistency and eventual consistency, and that I can't run ancestor-less queries inside transactions, but I don't  understand why I would test for eventual consistency. Maybe I have blackout here.

Ani

[Nick]

Unit testing with simulated eventual consistency by returning correct or stale reads using the set probability distribution.

This allows you to tweak what you're testing - e.g. Just to present everything as consistent stuff for ease of testing, or totally eventual stuff to guarantee that the code you're testing is using keys/transactions etc correctly.

They're really the only two scenarios that are interesting for most application unit tests - no one wants intermittent failing tests in the build process.

[Adam (Cloud Platform Support)]

The High Replication Datastore is the name for the current Datastore, as opposed to the old Datastore which was called Master / Slave.