没有软件域，TDD不适合或无效。然而，有些领域是具有挑战性的。游戏恰好是其中之一。

实际上，挑战不是游戏，而是UI。 UI的一个挑战是，你经常不知道你想要的UI，直到你看到它。 UI是你必须搞砸的事情之一。正确的做法是一个深刻的迭代过程，充满曲折，死胡同和后巷。首先为UI编写测试可能既困难又浪费。

现在大家都在咆哮说：“叔叔叔叔说：’不要做TDD的UI’”让我说这个。事实上，很难为UI做纯粹的TDD并不意味着你不能为几乎所有的东西做纯粹的TDD。许多游戏是关于算法，你可以使用TDD与这些算法，你的心的喜悦。这是真的，特别是在游戏，其中一些算法是那种代码，你必须搞砸，就像UI，所以可能不适合首先测试。但是有很多其他算法代码，可以和应该书面测试第一。

这里的窍门是遵循single responsibility principle (SRP)和分离那些种类的代码，你必须解决，从那些是确定性的。不要将易于测试的算法与您的UI。不要将您的推测代码与非推测代码混合。保持原因改变的事物与因原因B而改变的事物分开。

另外，记住这一点：事实上，一些代码很难测试，并不意味着这个代码很难测试第二。一旦你已经调整和调整，让代码按照你喜欢的方式工作，那么你可以写测试表明代码工作的方式你的想法。 (你会惊讶于你在这么做时发现错误的次数。)

编写测试“事后”的问题是，代码通常是如此耦合，很难写出最有帮助的各种外科测试。因此，如果你正在编写那种难以测试的代码，你应该注意遵循dependency inversion principle (DIP)和open/closed principle(OCP)，以保持代码足够的分离，以便在事实之后进行测试。