tdd - 测试驱动开发是游戏开发中的常规方法吗？

Question

我很好奇，因为我看到的所有TDD示例都与Web编程相关。如果这不是正常方法，为什么不呢？

Answer 1

TDD已成为认真对待其职业的软件开发人员的首选方法。该方法的好处是显着的，与之相比，成本也很低。 [IEEE:TDD]

没有任何TDD不适当或无效的软件域。但是，在某些 Realm 它具有挑战性。游戏恰好是其中之一。

实际上，挑战不只是游戏，而是UI。 UI面临挑战的原因是，您常常不知道UI的外观。 UI是您必须弄弄的东西之一。正确处理是一个深刻的迭代过程，充满曲折，死胡同和后巷。首先为UI编写测试可能既困难又浪费。

现在，在所有人怒吼之前，他说:“鲍勃叔叔说:'不要为UI做TDD'。”很难为UI做纯TDD的事实并不意味着您几乎不能为其他所有事情做纯TDD。许多游戏都与算法有关，您可以将TDD与这些算法结合使用，以使您心满意足。的确如此，尤其是在游戏中，其中某些算法就像UI一样，是您必须弄弄的那种代码，因此可能不适合首先进行测试。但是还有很多其他算法代码可以并且应该首先进行测试。

这里的技巧是遵循The Three Laws of TDD并将确定的代码类型与确定性的代码区分开。不要在用户界面中加入易于测试的算法。不要将您的推测性代码与非推测性代码混合使用。将因原因A更改的事物与因原因B更改的事物分开。

另外，请记住这一点:某些代码很难首先进行测试，但这并不意味着该代码很难进行第二次测试。一旦经过弄弄，调整和使代码按照您喜欢的方式工作，那么您就可以编写测试来证明该代码以您认为的方式工作。 (您会对执行此操作时发现错误的次数感到惊讶。)

“事后”编写测试的问题在于，代码经常耦合在一起，以至于很难编写最有用的外科测试。因此，如果要编写的代码类型首先很难进行测试，则应注意遵循single responsibility principle (SRP)和dependency inversion principle (DIP)(OCP)，以便使代码充分分离，以便事后进行测试。