如何设计可测试性代码

我一直在考虑在我未来创建的任何项目中使用 TDD 并实施适当的测试（才刚刚开始了解它如何使您的生活变得更好）。因此，在过去的几天里，我一直在 SO 上徘徊，试图了解如何设计可测试性的应用程序，但我似乎仍然在努力解决一些想法。

我读过很多你应该编程的内容针对接口而不是classes。我遇到的主要问题是，您应该创建多少个接口？您是否应该为您想要测试的所有内容准备一个？或者我读错了？

另一件事是使用大量依赖注入，因此您可以模拟您正在注入的部分，而不是使用真实的东西。它是否正确？或者我也离这里很远？

我认为你的想法是正确的，但我认为你把这件事变得比实际情况更大。如果您开始进行 TDD，您的第一反应可能是“是这样吗？”。然后，你应该会说“啊哈”！

最重要的是，您获得 nUnit，学习教程，然后确保在编写实现之前为您所做的一切编写测试。您可能会跳过为属性访问器编写测试，但任何需要计算的内容，您都应该首先编写测试。

因此，假设您正在测试计算器的 Add(int 1, int 2)，您首先想到的是“我怎样才能打破这个”。我认为可能出错的地方是：负数、零和溢出。诀窍是想象要创建 Add() 方法的人可能犯的每个错误，然后针对它编写测试。所以，我可能会写：

Assert.AreEqual(5, calc.Add(2, 3), "Adding positives not as expected");
Assert.AreEqual(-5, calc.Add(-2, -3), "Adding negatives not as expected");
Assert.AreEqual(-2, calc.Add(-3, 2), "Adding one positive and one negative not as expected");

// your framework might provide a cleaner way of doing this:
try {
  int result = calc.Add(Int32.Max, 5);
  Assert.Fail("Expected overflow error. Received: " + result);
} catch(Exception e) {
  // This should be a more specific error that I'm not looking up
}

因此，正如您所看到的，我试图做的是找出 Add() 方法可能不起作用的原因，然后对其进行测试。我还寻找了有趣的极端情况并明确定义了我期望的行为。现在我可以开始编写 Add() 方法的代码了。

现在，虽然这并不是那么好，但您知道，当您开始创建将 Sin() 方法与 Sqrt() 方法以及 Add() 方法结合起来的复杂数学函数时，您的 Add() 方法将坚如磐石。

无论好坏，这就是测试驱动开发。现在不要太关注接口或依赖注入。如果您需要的话，可以稍后再做。