试图在不熟悉域的情况下使用TDD

Question

背景：

我目前正在为学习目的创建我的第一个游戏引擎项目。这是我做过的第一个更大的项目。我知道在项目中涉及游戏引擎（比如分离的系统 - 输入，图形，音频，物理等）的更高层次的细节，但是当进入细节时，我很喜欢弄清事物随我走。我的编码过程，现在看起来是这样的：

1）找出我想设计

2）启动一些实验性的编码看到的东西需要究竟是如何工作系统的一些快速的，更高层次的细节

3.）一旦我对自己所拥有的东西感觉良好后再添加测试。

由于我对问题领域（游戏引擎编程）非常不熟悉，我发现我确实需要在代码中进行实验，以查看我需要哪些功能以及哪些设计套件最好。然而，我知道大多数社区（所以似乎无论如何）通常提倡更多的TDD方法来构建应用程序。我可以看到这样做的好处，但我不太清楚，当我真的不知道我真的需要测试哪些功能时，我会如何应用“先写测试，再失败，然后通过”。即使我能想到1或2个确定的函数，如果在实验阶段，我发现将这些函数分成不同类的更多函数更好。然后，我将不得不不断重新设计我的代码和我的测试。

我的问题/问题（S）：

那么，有没有方法可以使用，当你在代码中尝试TDD方法的好办法？或者，TDD通常是指那些熟悉他们工作项目的人，并且了解设计需要什么或者他们需要测试哪些功能？

Answer 1

一种常见的方法时，使用不熟悉的领域TDD：

• 做一些实验性的编码，以了解更多
• 预留的实验代码并启动TDD“测试第一”的方针
• 当你写生产代码让你的测试通过，你将会收获你的实验代码。

这种方法的好处是，通过TDD“红色，绿色，重构”循环，您通常会改进实验代码的设计。没有它，你的实验代码通常会变成一个“大泥潭”。

Answer 2

我发现当我让“我不习惯在这种情况下编写单元测试”成为不写单元测试的借口......我从不写任何单元测试。

如果您对代码行为有足够的了解，您就足够了解它的测试。

即使我能想到的1个或2个明确的功能，如果在 试验阶段，我觉得这是更好地跨越不同类别

如果你已经 拆分这些功能伸到更多的功能原始功能已经过测试，而且你只是在改变界面，那么应该有一些测试逻辑不得不改变。之后改变界面时没有任何破坏的风险。此外，这种担忧并不是专门针对新领域的实验。

也许陌生的领域不是开始学习TDD的最佳场所。但我肯定不会说这个过程本身不适合。