私はビヘイビア駆動開発に不慣れであり、現在の問題に対応する例やガイドラインを見つけることができません。
私の現在のプロジェクトには、個別のセルのそれぞれに任意の数のスロットがある大規模な3Dグリッドが含まれます。これらのスロットに格納されているエンティティには独自のスロットがあるため、エンティティの任意のネストが存在する可能性があります。使用されるオブジェクトの最終的な実装は、ある種の永続データストアによってサポートされる必要があります。これにより、APIが少し複雑になります（つまり、get/setの代わりにload/storeのような単語を使用し、返されたアイテムを変更しないようにします。データストア自体の対応するアイテムを変更します）。心配しないでください。私の最初の実装は単にメモリ内に存在しますが、APIは動作を定義することになっているものなので、実際の実装は今のところ重要ではありません。
私がこだわっているのは、BDDの文献がオブジェクト間の相互作用に焦点を当てているという事実と、モックオブジェクトがそれをどのように支援できるかということです。ここではまったく当てはまらないようです。私の抽象データストアの唯一の実際の「動作」には、プログラミング言語自体によって表されるエンティティ以外のエンティティからのデータのロードと保存が含まれます。これらの動作は実装に依存しているため、定義またはテストすることはできません。
では、何を定義/テストできますか？自然な選択肢は状態です。何かを保存します。ロードされていることを確認してください。ロードしたものを変更し、リロードした後、変更されていないことを確認します。などですが、これは新しいBDD開発者にとってよくある落とし穴であるという印象を受けているので、それを回避するためのより良い方法があるかどうか疑問に思っています。
私が州のテストルートをとる場合、他のいくつかの質問が発生します。明らかに、最初に空のグリッドをテストし、次に1つの場所で空のエンティティをテストできますが、次に何をしますか？異なる場所にある2つのエンティティ？同じ場所にある2つのエンティティ？ネストされたエンティティ？ネスティングをどのくらい深くテストする必要がありますか？これらの非排他的なケースのデカルト積をテストしますか？つまり、同じ場所にある2つのエンティティと、それぞれネストされたエンティティを使用しますか？リストは永遠に続き、どこで止めればいいのかわかりません。