unit-testing - 具有副作用的单元测试功能？

Question

假设您正在编写一个函数来检查是否通过适当的 URL 访问了页面。该页面有一个“规范” stub - 例如，虽然可以在 stackoverflow.com/questions/123 访问页面，但我们更愿意(出于 SEO 原因)将其重定向到 stackoverflow.com/questions/123/how-do -i-move-the-turtle-in-logo - 并且实际的重定向安全地包含在它自己的方法中(例如，redirectPage($url))，但是如何正确测试调用它的函数呢？

例如，采用以下函数:

function checkStub($questionId, $baseUrl, $stub) {
  canonicalStub = model->getStub($questionId);
  if ($stub != $canonicalStub) {
    redirectPage($baseUrl . $canonicalStub);
  }
}

如果您要对 checkStub() 函数进行单元测试，重定向不会妨碍您吗？

这是一个更大问题的一部分，其中某些功能似乎变得太大而离开单元测试领域并进入集成测试领域。我的脑海中立即想到路由器和 Controller 存在这些问题，因为测试它们必然会导致页面的生成，而不是仅限于它们自己的功能。

我只是在单元测试中失败了吗？

Answer 1

你说...

This is part of a larger problem where certain functions seem to get too big and leave the realm of unit testing and into the world of integration testing

我认为这就是为什么单元测试(1)很难并且(2)导致代码不会因自身重量而崩溃的原因。您必须小心翼翼地打破所有依赖关系，否则您最终会遇到单元测试 == 集成测试。

在您的示例中，您将注入(inject)重定向器作为依赖项。您使用模拟、双重或 spy 。然后按照@atk 的说明进行测试。有时这不值得。更多的时候，它会迫使你编写更好的代码。没有 IOC 容器就很难做到。