使用测试驱动开发时俄罗斯方块的验收测试

Posted 2023-02-23

【中文标题】使用测试驱动开发时俄罗斯方块的验收测试

【英文标题】：Acceptance Tests for Tetris when using Test Driven Development

【发布时间】：2010-07-24 05:28:54

【问题描述】：

我想尝试使用 TDD 实现俄罗斯方块游戏。

根据我在阅读Growing Object-Oriented Software, Guided by Tests 时的理解，我应该首先定义我的验收测试。如果我是对的，做 TDD 时的验收测试就像用例一样定义。

定义一个好的第一个验收测试作为应用程序的“骨架”非常重要，所以它应该很简单。

我选择了以下 2 个验收测试作为我的第一个实施：

游戏开始，玩家关闭游戏。 游戏开始，玩家什么也不做。他最终输了。

这 2 个验收测试是很好的开始测试吗？什么是好的下一个验收测试？我可以想到类似的东西

游戏开始，只有方块掉落。玩家将它们全部放在这样的方式下，即线条总是“爆炸”，使得 100 个游戏步骤后的游戏仍未结束。

但我觉得这有点尴尬，因为在真正的俄罗斯方块游戏中，你总是会有不同的碎片掉下来，这就是验收测试应该做的。

此外，在执行 (2) 时，我有点想尝试一次性实现所有内容，我认为在实施第二个验收测试时不会假装。我想这个想法是只在其中 6-7 个之后才实施游戏，而不是在第二个。我说的对吗？

谢谢

【参考方案1】：

我会首先考虑游戏领域，以及在丢弃一些定义的块的若干帧之后它的样子。例如使用Cucumber:

Scenario: dropping the first square
  Given an empty 10x2 field

  When a square is dropped at column 4
  And 48 frames have passed

  Then the field should contain a square at (4, 1)

  When 48 frames have passed
  Then the field should contain a square at (4, 2)

Scenario: Dropping a square on a full stack
  Given an empty 10x2 field
  And a square at (4, 2)

  When a square is dropped at column 4
  And 48 frames have passed

  Then the game should be over

如果您喜欢 Cucumber 功能规范的外观，您可能想尝试使用 .Net 的 Cuke4Nuke 或 Java 的 Cuke4Duke。

【讨论】：

我不清楚数字 48 的来源。另外，对于第二种情况，Given 短语是否应该改为“Given a full 10x2 field”？

我查看了俄罗斯方块的***页面以获取商业语言。这就是 48 的来源。 “一个完整的 10x2 场”可能是一个很好的假设，但不是很现实，我曾经玩过一些俄罗斯方块，但从未见过一个完整的场。

我在理解如何使用 TDD 时遇到了一些麻烦，也就是说，对于每个测试，如果我们实现您提供的场景，我们应该尽可能少地运行代码以使某些东西运行。我的意思是，我已经可以实现完整的俄罗斯方块游戏了，但是我很难想象如何实现所需的东西，而不必把它全部放在那里。

我所展示的将是一个验收测试。从验收测试开始。如果您有信心可以在没有错误的情况下实现这么多功能，那就去做吧。如果该行为不是微不足道的，请编写第一个较低级别的测试并使其通过。然后下一个。如果您仍在朝着验收标准前进，请继续前进，如果没有，请删除代码并重新开始。有时，在我理解代码的编写方式之前，我会多次进行单元测试（低级规范）路径。仔细听，它会告诉你的。

你做的那些验收测试和俄罗斯方块类的单元测试有什么区别？

【参考方案2】：

您需要从测试中移除游戏中的随机性。是的，这意味着测试并不能完美地复制游戏，但这也意味着您有可重复的测试，这具有更大的价值。隔离差异 - 将 PieceProvider 传递到您的游戏中；对于真正的游戏，传递一个 RandomPieceProvider，但对于测试，传递一个 SpecifiedPieceProvider。现在它们之间只有一点点差异，但差异应该小到无关紧要；您仍然可以满怀信心地测试游戏的所有其他方面。

【讨论】：

public Random(long seed) 构造函数可以轻松创建可重复但合理的测试：download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/…

是的，这是真的。但更困扰我的是如何实现第一个场景/用例。问题是我应该对游戏本身实施多少。

@devoured 我没有读过你提到的那本书，但我看到的关于 TDD 的大部分建议是：只要通过测试就行。它对我来说效果很好。

【参考方案3】：

从一个简单的块列表开始。假设没有玩家，积木将以某种方式堆积起来，然后溢出。如果块没有正确堆叠或程序未检测到溢出，则您的测试失败。

【讨论】：

我怎么知道他们没有堆叠正确？那么我是否必须实现比我正在尝试制作的更复杂的代码逻辑？还是你假设我只是在游戏中选择了一组选定的棋子？你说的是单元测试还是验收测试？

我假设了一组精选的作品。