游戏中使用BDD（行为驱动开发）吗？

我已经阅读了一段时间有关BDD-行为驱动的开发的文章，并且发现将功能转换为代码确实非常容易和有用。BDD用户经常称其为TDD做得正确。

BDD是一种从业务内部到业务，从业务价值（或游戏价值）到代码进行软件设计的工具。

Dan North介绍BDD

你知道BDD和游戏比其他任何资源这个？

可以肯定地说BDD，例如TDD，或（在此处插入流行的流行语开发范例）在某些地方被某些游戏开发人员使用，但是他们可能不知道它们是谁，也不一定能够确定BDD的实际含义。 。真正的问题是多少，他们使用它，做多少，他们都用它为它关系到你？

例如，在我工作的地方，我们所有的单元测试名称都是“句子”，就像Dan North在您链接的文章中所建议的那样。当然，仅凭这一点还不足以说我们使用了BDD，但这也许正是您真正关心的吗？

在我看来，重点不应放在您在工作室使用的流行语上，而应该放在您整体采用的生产力和开发过程技术上。我发现，最有生产力的团队正在混合和匹配来自各种“流行语范例”的技术，而不是教条地致力于某些互联网研究说构成一个特定流行语范例的严格理论。

我最常在敏捷趋势中看到这一点：将自己标识为“在做敏捷”的团队比在团队中有机地融合了对他们有意义的一点的团队，在流程上往往更加僵化（具有讽刺意味）。根据我的经验，前几支球队几乎总是​​效率低下。

一个开发团队是由人类组成的，他们不是机器中可互换的齿轮。它们作为个体和自身的独特组合而独特地运作。有效发展的方法不是使您的团队陷入{BDD，Agile，WhateverIsNext}的模范中，而是不断地重新评估团队的进度和弥补流程中的缺陷，替换损坏的技术并增强已经存在的事物。工作。简而言之，专注于发布标题，而不是“敏捷（或其他）”。

是吗？也许。我的看法是，尽管它可能对于低级库很好用，但它通常会使娱乐软件的适应性很差。

编辑：这是我的观点。

Wikipedia将BDD定义为一种“鼓励软件项目中的开发人员，QA和非技术或业务参与者之间进行协作的技术”。这听起来似乎是个坏主意，因为游戏不同于大多数软件，因为游戏并非设计为满足“非技术或商业参与者”的特定需求的工具，而是具有广泛凝聚力的娱乐性作品。强调“所需的软件行为”，但游戏在技术层面上很少具有“所需的软件行为”。检查代码的那部分绝对是有好处的，但是与最终用户不要检查，因为他们永远也看不到它。

但是，让我们假设您想扔掉人类利益相关者的东西，而只是使用BDD在不同代码模块之间执行合同，据我所知，这与正常的测试驱动开发并没有太大的区别，我也认为这很差-适用于游戏，原因如下。

测试对于检查离散事件是否按预期发生很有用。这在事件驱动的编程中效果很好，即。在执行操作的大多数软件世界中，都会生成一些输出，然后您只需验证操作和结果是否匹配即可。但是，游戏软件通常是模拟，其中动作没有离散结果，而是世界状态的连续变化。如果我的隐藏玩家发出声音，我可能要检查AI是否使我失望。因此，我可以创建一个测试来确保在创建噪音后AI处于“狩猎”状态，这很棒。但是我怎么知道打猎还行呢？您无法立即检查-您只能随时间推移进行观察。

此外，测试优先的方法可能会产生错误的安全感，并使人们认为代码比实际要好。

def check_dice_roll_in_range():
    d = new Dice()
    assert(d.roll() between 1 and 6)

class Dice:
    def roll():
        return 4

由于测试结果可能会导致误报，因此您永远无法逃脱检查代码本身的基本需求。但是，如果对代码本身进行了充分的检查，则测试将具有次要的重要性。我认为，这就是在事件发生后最好使用测试来测试错误修复的原因。

我不会争辩说测试对象X和Y一起工作时，您得到的结果是预期的，永远不会有任何好处。问题是您是否正在使用最有效的方法进行验证。方法可以包括形式验证，代码审查，先测试方法，后测试方法，传统的质量检查黑盒测试，或仅按预期使用代码并观察结果。最后两个选项在大多数情况下都出乎意料地有效，因为尽管听起来似乎不那么严格，但大多数错误是在典型使用过程中发现的，因此，了解自然环境中的错误有时比在人工测试中理解它更容易。马具。最重要的是

因此，总而言之，我认为测试驱动的开发不一定是软件的理想选择，仅凭测试永远不足以确保软件质量（因此，必须将编写这些软件的时间与该开发人员的其他使用时间进行比较），游戏对于自动化测试用例而言尤其不理想，而对于强调“业务价值”和“验收测试”的开发方法而言，游戏尤其不理想。

（希望这是一个更好的答案，即使您不同意我的观点。）

我认为BDD适用于每种环境。正如其他人提到的那样，您正在开发软件，因此应进行测试。对于某些随机语义，例如测试名称作为句子，我确实喜欢bdd。我还喜欢将某些测试分组在一起，同时仍然可以测试1个班级。

为了与其他消息抗衡，我想指出的是，在较大的项目中，没有测试就很难重构代码。如果重构某些代码，那么您会无视于一切是否会因荣耀而爆炸。测试可帮助您及早发现问题。因此，您编写测试，失败，代码正好足以通过并继续。重构时，您应该做同样的事情，而不是编写，而是修改测试。在大多数情况下，您运行测试会失败，然后更改您认为应该更改的内容，但它仍然失败。在这一点上，您意识到其他一些代码完全以不同的方式依赖此函数/方法。然后，您可以修复测试和生成的代码。如果没有这种代码覆盖率，您将要花费数天的时间来尝试查找损坏的地方，

在实用程序员的书中阅读有关“合同”的信息。测试可以帮助您达成代码合同。这段代码只执行X，仅执行X，不要指望它对Y做任何事情，也不希望尝试使其适应Z。它可以确保代码的清洁度，并希望每个人都不要笨拙并弄乱代码库。

进行BDD的原因更多。对我来说主要的是无论如何我都会做相同数量的测试来验证我的假设，所以我也可以将其形式化。

关于“如何”，这实际上取决于您的环境。我现在正在编写Java游戏并使用robolectric。您应该始终尝试“期待”某件事。我听说间谍/模拟/存根不那么有用，因为您需要在另一侧具有等效功能，但是有时您别无选择，尤其是使用API​​。您可以假定API的另一端并不糟糕，通常是您的代码很烂。

例如，如果您正在测试运动。好吧，您希望在按下“向上”按钮时，用户可以通过某种测量向前移动。

例如，如果您正在测试图形渲染...那么不要测试太多，因为您确实在这样做吗？一个好的测试框架可能会为您处理这一部分。对于这些事情，我不会说反思。您可能需要检查缓冲区等。我只是检查您实际在做什么。角色在这里，现在他经过一番行动就在那里。

您应该有很多微小的小功能/测试，它们一起可以总结出一些有用的东西。

我觉得对BDD是一个误解。BDD不是测试技术或过程。BDD是一个开发模型和过程。它超出了测试范围，也超出了编程范围。

因此，我不知道任何主要的AAA工作室都在使用这种模型（我有很多朋友以程序员的身份在世界各地为他们工作）。正如其他人指出的那样，可能是某个项目经理或某个团队在某处合并了BDD所包含的一些实践，但是我不知道任何工作室都在应用纯BDD（从业务价值定义，示例规范到编写）功能文件，与股东进行验证，将功能文件作为测试自动化）。