我正在尝试正确地做 TDD！我正在阅读有关 TDD Inside Out 而不是 Outside In 的内容。原因是我不知道我的层是如何预先设置的，所以我的想法是开始编写测试，让它失败，然后开始编写我的第一层。
在编写我的第一层时，我注意到我需要另一个层，我们称之为服务层。这就是我感到困惑的地方，我该怎么办？
我是否停止并创建一个失败的新测试，以便我可以使用 TDD 实现我的新服务层？完成后，我回到原来的层，我应该在这里创建我的服务层的模拟吗？还是使用我刚刚通过 TDD 创建的服务层？
这是TDD吧？因此，如果我在嘲笑事情，那么也许我的 TDD 并没有推动我的发展？但是，当然，如果我不进行模拟，这些技术上不是单元测试，而是更多的集成测试？
如果确实我的单元测试（通过 TDD 编写）使用模拟，那么我需要进行一些其他类型的测试来测试每个单独层作为一个单元的集成？
集成测试还是 e2e 测试？
我认为我的问题基本上是当我需要引入新层时，我应该模拟这些，我应该创建一个新的测试来推动这个新层的开发吗？
我希望有人可以帮助解开我自己陷入的这个混乱！
谢谢
有了更多的经验，你会变得更好。但现在让我说这些。
首先，将 TDD 视为设计干净代码的工具（查看Uncle Bob's Clean Code以获得更多见解。）。它绝不会取代任何系统设计工作。这意味着您必须知道您希望类设计什么（至少大致如此），并且您还必须定义这些类之间的接口。
其次，根据Mike Cohn - Working Effectively with Legacy Code - Chapter 2的单元测试是不会：
所以，你应该在单元测试的范围内很好。
通常，您希望为每个组件（或类）编写单元测试。这意味着您为每个接口创建假类或模拟，例如为每个服务层类。这意味着您必须知道每个调用所需的确切接口（方法参数和返回值）。尝试使用一个实例尽可能多地到达，然后继续进行下一个实例。
如果您不确定设计的外观，请考虑构建未经测试的原型。尽可能多的代码让您看到组件协同工作并帮助构建您的界面。然后勾勒出设计草图，扔掉你的原型，从 TDD 方法重新开始。
在以 TDD 风格进行开发时，您应该尽可能多地使用接口。
单元测试意味着您测试与大多数（理想情况下所有）其他代码隔离的每个单元。
因此，在您的情况下：如果您当前处理的代码需要调用某个服务层。然后 jsut 为新模块创建一个接口并模拟它们的正确行为（或者如果您想测试错误处理，则为预期的错误行为）。
...并将测试您的新服务层放在您的待办事项列表中；）
这样，当您开始工作时，您可以将工作集中在当前单元上，并为您的服务层准备好接口。
如果你想测试你的层如何协同工作，你需要某种集成测试。