これまで結果整合性 (高レプリケーション) を使用していなかったアプリ (Google アプリ エンジン + 高レプリケーション データストア) があり、すべてのテストが完全に機能しました。
現在、高レプリケーションでのローカル テストでは、結果整合性に移行するとすぐに失敗し始めます。どうすればそれを防ぐことができますか? または、その部分をどのようにテストしますか？x-entity トランザクションに必要です。
https://developers.google.com/appengine/docs/python/tools/localunittesting#Writing_HRD_Datastore_Testsに似たものを使用しています
編集：
コードを正しくテストする必要があります。私が抱えている問題は、テスト部分にあります。結果整合性をテストする方法
編集1：上記のリンクされた例で確率= 100％を使用して問題を一時的に解決しました。しかし、アイデアは大歓迎です。
障害を修正します。
あなたはコードを持っておらず、非常に曖昧なので、あなたの質問に答えるのは難しいです。ただし、基本的に、アプリコードまたはテストのいずれかが結果整合性を考慮していません（つまり、クエリがデータベースで更新されたばかりの値で返されない場合があります）。データストアで結果整合性をオンにすると、取得するクエリ結果が異なります。
トランザクションとの結果整合性の状況を処理するためにコードを更新するか、結果整合性の結果を期待するためにテストを更新する必要があります。
編集
この質問はまだ一般的すぎます。機能テストとシステムテストのどちらを行っているかによって異なります。特定の結果をお探しですか？または、HTTPステータス= 200だけですか？
一般に、すべてのテストと同様に、何が成功を構成し、何が失敗のケースを構成するかを特定する必要があります。特定の状況で、古いデータが表示されることは許容されますか？その場合、テストは古い値または新しい値のいずれかで成功するはずです。
決定論的テストと非決定論的テストのどちらを実行するかを検討することから始めることをお勧めします。決定論的テストの場合、基本的に、確率=0と確率=100で同じテストを実行し、両方の値が正しいことを確認する必要があります。
ストレステスト以外の完全に有用な方法で非決定論的テストを書く方法を私は理解していません。特定の必須値が満たされていること、および他の結果整合性のある値が有効な範囲内にあることを確認できます。これは多くの作業です。別の値の範囲に依存する可能性のある値の範囲があり、最終的な出力が両方で構成されている可能性があるため、組み合わせが正しいことを検証する必要があります。すべてが正しいことを本当に確認したい場合は、アプリケーションロジックの一部を再現します。
あなたが直面している状況は、高レプリケーション データ ストアの欠点 (または機能と呼びます) の 1 つです。通常、これらの状況は、memcache を使用した透過的なキャッシュによって対処されます。以前に db マスター/スレーブ アーキテクチャを使用した経験がある場合、スレーブ ラグは同様の方法で取り組まれます。