【发布时间】：2009-05-19 21:12:44
【问题描述】：
假设您有一个通过所有当前单元测试的类。
如果您要添加或提取一些方法/引入一个新类，然后使用组合来合并相同的功能，那么新类是否需要测试？
我在你是否应该这样做之间犹豫不决，所以任何建议都会很棒。
编辑：
假设我应该添加我使用 DI（依赖注入）因此我应该注入新类吗？
【问题讨论】：
标签： unit-testing tdd dependency-injection
【发布时间】：2009-05-19 21:12:44
【问题描述】：
不是在 TDD 的上下文中，不，恕我直言。现有的测试证明了关于类存在的一切。如果您需要向类添加行为，那就是时候引入测试了。
话虽如此，将测试移到与您创建的新类相关的类中可能会使您的代码和测试更清晰。这在很大程度上取决于具体情况。
编辑：在您进行编辑后，我想说这为移动一些现有测试（或现有测试的一部分）提供了一个很好的案例。如果类是如此解耦以至于需要注入，那么听起来如果现有测试留在原地，它们可能不会明显覆盖它。
【讨论】：
-
我就是这么想的——不过对于 DI 我应该怎么做呢？我是否应该在构造函数中创建并初始化新类的具体实现，而不用担心注入它——毕竟它的作用与以前一样？
-
DI 的重点在于能够互换组件。如果你永远不会（我的意思是永远不会）将你的新课程换成其他东西，我会继续自己构建它。
最初，不，它们不是必需的。如果你有完美的覆盖，提取类并且什么都不做，你仍然会有完美的覆盖（并且这些测试将确认提取确实是一个纯粹的重构）。
但最终——可能很快——是的。提取的类可能会在其原始上下文之外使用，并且您希望使用特定于新类的测试来限制其行为，以便新上下文的更改不会无意中影响原始调用者的行为。当然，原始测试仍然会揭示这一点，但是好的单元测试会直接指向有问题的单元，并且原始测试现在被移除了一个步骤。
将新测试作为新提取的类的可执行文档也很好。
【讨论】：
嗯，是的，也不是。
如果我理解正确，您已经编写了测试，并编写了使测试通过的生产代码 - 即最简单的工作。
现在您处于重构阶段。您想从一个类中提取代码并将其放入自己的类中，可能是为了跟上单一职责原则（或 SRP）。
您可以在不添加测试的情况下进行重构，因为您的测试正是为了让您无需担心地进行重构。请记住 - 重构意味着更改代码，而不修改功能。
但是，重构代码很可能会破坏您的测试。这很可能是由测试行为而不是状态的脆弱测试引起的 - 即您嘲笑您移植的方法。
另一方面，如果您的测试主要是状态驱动的（即您断言结果，而忽略实现），那么您的新服务组件（您提取到新类的代码块）将不会被测试。如果您使用某种形式的代码覆盖率测试工具，您就会发现。如果是这种情况，您可能希望测试它是否有效。 可能，因为 100% 的代码覆盖率既不理想也不可行。如果可能，我会尝试为该服务添加测试。
最终，它很可能归结为一个判断电话。
【讨论】：
我会说不。它已经通过在旧类上运行的测试进行测试。
【讨论】：
正如其他人所说，它可能并不完全需要，因为所有相同的东西仍在测试中。但是，一旦您开始单独更改这两个类中的任何一个，您就应该将测试分开。
当然，测试不应该太难写；既然你已经有了正在测试的东西，那么分解测试的各个部分应该是相当简单的。
【讨论】：