我是行为驱动开发的新手，我找不到任何与我当前问题相似的示例或指南。
我目前的项目涉及一个巨大的 3D 网格，每个离散单元中都有任意数量的插槽。存储在这些槽中的实体有自己的槽，因此可以存在任意嵌套的实体。使用的对象的最终实现将需要某种持久数据存储的支持，这会使 API 有点复杂（即使用 load/store 之类的词而不是 get/set 并确保修改返回的项目不会修改数据存储本身中的相应项目）。别担心，我的第一个实现将简单地存在于内存中，但 API 是我应该定义的行为，因此实际的实现现在并不重要。
我坚持的事实是 BDD 文献关注对象之间的交互以及模拟对象如何帮助实现这一点。这似乎根本不适用于这里。我的抽象数据存储唯一真正的“行为”涉及从编程语言本身所代表的实体之外的实体加载和存储数据；我无法定义或测试这些行为，因为它们依赖于实现。
那么我可以定义/测试什么？自然的选择是状态。存储一些东西。确保它加载。修改我加载的东西，并确保在我重新加载后它没有被修改。等等。但我的印象是，对于新的 BDD 开发人员来说，这是一个常见的陷阱，所以我想知道是否有更好的方法来避免它。
如果我确实采取了州测试路线，则会出现其他几个问题。显然我可以先测试一个空网格，然后在一个位置测试一个空实体，但接下来呢？不同位置的两个实体？同一位置的两个实体？嵌套实体？我应该测试多深的嵌套？我是否测试这些非排他性案例的笛卡尔积，即同一位置的两个实体并且每个都有嵌套实体？清单永远持续下去，我不知道在哪里停下来。