假设我正在编写一个使用测试驱动开发的应用程序。 我找到的所有示例都是非常小的示例，它们试图解释如何用 TDD 编写测试。
当您在 TDD 中编写测试时，您会编写一小段代码，其目的是测试一段代码、一个方法，即单元测试。
一段时间后，收到来自客户的需求，您需要更改原始代码，使其能够接受更多参数，并将方法拆分为多个层上的多个方法。
假设发生故障时添加日志记录。那么我需要测试什么，日志组件单独测试，还是与原始方法链接在一起？
这意味着原来的单元测试实际上变成了集成测试，因为我现在正在一起测试多个组件。
这是应该避免的事情吗？或者如果需要，人们如何解决这类问题？
亲切的问候
最佳答案
现实世界中的 TDD 实际上同时使用了单元测试和集成测试。在教程中看到单元测试是因为它更容易理解简单的例子，但真正的应用程序需要一些集成测试。您编写的第一个测试通常是集成测试(请参阅 bdd)。
但是，集成测试速度慢且难以维护(与单元测试相比，它们接触的系统更多，因此更改更频繁)，因此最好只进行所需数量的集成测试并进行尽可能多的测试进行单元测试是合理的。
当对某个类的要求导致它变得更大并且您将该类重构为更小的类时，它的单元测试现在是集成测试。通过为新类编写有针对性的单元测试并删除原始类的大部分旧测试来解决这个问题。留下一个或几个旧测试作为集成测试可能是合适的。重写一些旧测试以将测试替身( stub 、模拟等)用于其他类的现在实例也可能是合适的。巧合的是，我最近写了an answer about the mechanics of rewriting tests when you refactor a class out of another class .
关于unit-testing - 单元测试成为 TDD 的集成测试，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37141304/