我一直在寻找使用TDD并在我将来创建的任何项目中实施适当的测试(才开始了解它能让你的生活有多好).因此,在过去的几天里,我一直在努力学习如何设计可测试性的应用程序,但我似乎仍然在努力解决一些想法.
我已经阅读了很多你应该针对接口而不是类编程.我遇到的主要问题是,你应该创建多少个接口？您是否应该为要测试的所有内容提供一个？还是我读错了？
另一件事是使用大量依赖注入,因此您可以模拟您注入的部分而不是使用真实的东西.它是否正确？还是我离开这里了？
我认为你有正确的想法,但我认为你正在把它变成一个比它更大的交易.如果你开始做TDD,你的第一反应可能就是’这是吗？’.然后,你应该说’啊哈’！
原文链接：https://www.f2er.com/javaschema/281465.html最重要的是你获得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()方法结合起来.
无论好坏,都是测试驱动开发.暂时不要过于依赖接口或依赖注入.如果你需要它,可以在以后发生.
