如何设计可测试性代码

Question

我一直在寻找使用TDD并在我将来创建的任何项目中实施适当的测试(才开始了解它能让你的生活有多好).因此,在过去的几天里,我一直在努力学习如何设计可测试性的应用程序,但我似乎仍然在努力解决一些想法.

我已经阅读了很多你应该针对接口而不是类编程.我遇到的主要问题是,你应该创建多少个接口？您是否应该为要测试的所有内容提供一个？还是我读错了？

另一件事是使用大量依赖注入,因此您可以模拟您注入的部分而不是使用真实的东西.它是否正确？还是我离开这里了？

Answer 1

我认为你有正确的想法,但我认为你正在把它变成一个比它更大的交易.如果你开始做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()方法.

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

无论好坏,都是测试驱动开发.暂时不要过于依赖接口或依赖注入.如果你需要它,可以在以后发生.

Answer 2

首先.. TDD是No Magic/Silver Bullet.用这个投入一些时间......这将是值得的.不要试图在飞行中或在SO-post上接收TDD.拿起一本好书(肯特贝克/戴夫阿斯特尔斯),然后继续努力......(看到人们在他们所需要的时候匆匆忙忙地退后一步阅读,真令人沮丧.)

可测试性设计:

• 首先编写代码测试..您的可测试设计应该出现..一次通过测试.你得到它作为副产品..更像是一种正确的做法.
• 一厢情愿:想象一下,你想要建立的东西已经存在.你会怎么跟它说话？这个简单的模拟应该为您提供'the thing'的外部接口定义

• 保持简单/ YAGNI /抓住锤子:投入一些时间来查看实践(模式,DI,模拟,你会发现很多等),以找出它们存在的原因.评估您是否需要它们,然后继续使用它们.另一个值得关注的好处是"哪里不使用它们？".如果这听起来像个坏主意......可能就是这样.(例如,我是否需要一个接口来为我编写的每个类做PR ...可能不是.我创建的每个类都需要Spring.net吗？)在每个检查点询问以下问题(K. beck对简单设计的定义) )

  • 代码和测试是否沟通了我需要沟通的一切？
  • 有没有重复？(如果有的话,消除)
  • 它是否包含尽可能少的类？...尽可能少的方法？有什么我可以从这个设计中拿走并仍然保留行为.

• 无情地重构:听听Martin Fowler并保持这本书的方便

(这是一个有趣的过程,试图提炼你做的选择几步:)感谢有机会反思)