TDD是否意味着不考虑课堂设计？
我正在制作角色扮演游戏以获得乐趣并尝试在开发时使用TDD。 我看到的许多TDD示例都侧重于首先创建测试，然后创建使测试通过所需的对象。
例如：
[Test] public void Character_WhenHealthIsBelowZero_IsDead() { // create default character with 10 health Character character = new Character(); character.SubtractHealth(20); Assert.That(character.IsAlive, Is.EqualTo(false)); } 所以基于此我将创建字符类和适当的属性/方法。 这似乎很好，但我的class级设计真的应该不断改进我的测试吗？ 这比制定我的游戏提前需要的可能对象更好吗？ 例如，我通常会想到一个基本的Character类，然后是子类，例如Wizard，Fighter，Theif。
或者是一种平衡的方法？ 我在哪里绘制出我需要的可能的类和层次结构，但首先编写测试以validation它们实际上是否需要？
我的class级设计真的应该不断改进我的测试吗？
是。
TDD是否意味着不考虑课堂设计？
绝对不。 它意味着在编写测试过程中考虑类设计，以及代码的其余部分。 在Red-Green-Refactor TDD生命周期中，类设计正在发挥作用。
我想你错过了TDD的观点。 TDD不是关于编写测试 – 它是关于设计你的类是可测试的。 这自然会带来更好的设计和实施。
听起来你正在倒退。
你的步骤应该是：
- 设计您的域模型
- 设计你的课程
- 写一些测试
- 实现一些类逻辑
- 重构您的类，以便在必要时使它们更易于测试
- 重复步骤3-5
我认为通常（通过TDD纯粹主义者）假设程序员通过编写测试设计应用程序已经了解设计和架构。 否则，你可以通过编写测试来放弃任何设计原则，将自己描绘成编程混乱和无政府状态。
因此，编写应用程序“首先测试”的开发人员已经对他的最终类结构将会是什么样子有一个公平的想法，并且该视觉指导他在编写测试时。
TDD是关于让测试推动您的设计，包括您的课堂设计。 这很有价值，因为测试旨在certificate代码“有效”。 这意味着你最终会得到一个有效的程序的类设计，而不是一个程序的类设计可能会或可能不会工作。
我认为平衡的方法是你需要采取的方法。 首先为你的域的类建模，因为没有它们， 你怎么知道要测试什么？
然后，你可能会创建这些类的存根或shell，主要是空实现，只是为了让你编写一些测试结构。
完成后，您的测试用例可能会说明对原始设计中没有的新方法/类/属性的需求，但发现它们是必要的。
平衡的方法是要走的路。
但是，平衡是由需要测试驱动的。
您可以映射出可能的类和层次结构。 但是，您需要通过（1）考虑可测试性和（2）在编写太多代码之前编写测试来驱动设计。
对于甚至编译的测试，您需要一些类定义。 他们不必工作，但他们必须编译。
在少数情况下，你的课程可能很简单，你实际上首先写下它的全部（或几乎全部）。
TDD倾向于使用运行代码而不是抽象地使用铅笔和纸来具体地思考和试验类设计。
这两种方法都很有用。 即使是铁杆TDD狂热者有时也会使用铅笔纸（或许是白板），BDUF-ueber-alles类型会偶尔使用原型。 那么问题就在于你倾向于堕落：沉思或更多动手？
TDD是关于设计的！ 所以做TDD你将确保你的设计完全可测试。
此外，“平衡的方法”是IMO的方式。 您已经了解了高级架构，TDD将推动该架构的可测试性。
编辑：虽然，如果你只是想练习TDD我不会做“平衡的方法”。 我会用“婴儿步骤”做TDD并且可能编写Dojos