我是行为驱动开发的新手，我找不到任何与当前问题相关的示例或指南。
我目前的项目涉及一个巨大的3D网格，每个离散单元格中有任意数量的插槽。存储在这些槽中的实体具有它们自己的槽，因此，可以存在任意实体嵌套。所使用的对象的最终实现需要由某种持久数据存储支持，这会使API复杂化（即使用诸如加载/存储之类的单词而不是get / set并确保修改返回的项目不会修改数据存储本身中的相应项目）。别担心，我的第一个实现只是存在于内存中，但API是我应该定义的行为，所以实际的实现现在并不重要。
我坚持的事实是BDD文献关注对象之间的交互以及模拟对象如何帮助它。这似乎根本不适用于此。我的抽象数据存储唯一真正的“行为”涉及从编程语言本身所代表的实体之外的实体加载和存储数据;我无法定义或测试这些行为，因为它们依赖于实现。
那么我可以定义/测试什么？自然的选择是国家。存放一些东西确保它加载。修改我加载的东西，并确保在我重新加载它之后不加修改。等等。但我的印象是，这是新BDD开发人员常见的陷阱，所以我想知道是否有更好的方法可以避免它。
如果我采取国家测试路线，还会出现其他几个问题。显然我可以先测试一个空网格，然后在一个位置测试一个空实体，但下一步是什么？两个实体位于不同的位置？两个实体在同一个位置？嵌套实体？我应该测试嵌套的深度？我是否测试这些非排他性案例的笛卡尔积，即同一位置的两个实体和每个嵌套实体？这个名单永远存在，我不知道该停在哪里。
答案 0 :(得分：1)
TDD和BDD之间的区别在于语言。具体而言，BDD专注于功能/对象/系统行为，以改善设计和测试可读性。
通常，当我们考虑行为时，我们会考虑对象交互和协作，因此需要进行单元测试。但是，对象的行为是修改网格的状态，如果合适的话，则没有任何问题。基于状态或模拟的测试可以在TDD / BDD中使用。
但是，为了测试复杂的数据结构，您应该使用Matchers（例如Java中的Hamcrest）来仅测试您感兴趣的状态部分。您还应该考虑是否可以将复杂数据分解为协作的对象（但只有从算法/设计的角度来看才有意义）。