在项目的哪些部分编写单元测试几乎或真正不可能?数据访问?ftp?
如果这个问题有答案,那么 %100 的覆盖率就是一个神话,不是吗?
在项目的哪些部分编写单元测试几乎或真正不可能?数据访问?ftp?
如果这个问题有答案,那么 %100 的覆盖率就是一个神话,不是吗?
这里我通过haacked的博客发现了Michael Feathers的观点,他相信以下几点可能成为区分单元测试的标准:
他说:
如果一个测试:
那么它就不是一个单元测试。
- 与数据库通信
- 跨网络通信
- 涉及文件系统
- 不能同时运行于其他单元测试中
- 需要对环境进行特殊设置(例如编辑配置文件)才能运行
同一篇文章中,他补充道:
通常情况下,单元测试应该很小,测试一个方法或者两个方法之间的交互。当你把数据库、套接字或者文件系统访问引入到你的单元测试中时,它们不再仅仅关注于那些方法本身,而是关于你的代码与其他软件集成的问题。
认为100%的测试覆盖率是一种神话,但这并不意味着80%的测试覆盖率没有用。当然,目标是达到100%,通过单元测试和集成测试,可以逐步接近这个目标。
在单元测试中,不可能预测顾客对产品做出的所有奇怪操作。一旦开始发现这些令人难以置信的代码变形,确保将它们的测试回归到测试套件中。
实现100%的代码覆盖几乎总是浪费的。有许多相关资源。
没有什么是不可能进行单元测试的,但总会有收益递减。对于难以进行单元测试的东西进行单元测试可能不值得。
目标并不是100%的代码覆盖率,也不是80%的代码覆盖率。编写单元测试容易并不意味着您应该编写它,而编写单元测试困难并不意味着您应该避免努力。
任何测试的目标都是以最实惠的方式检测用户可见问题。
编写、维护和诊断测试所标记的问题(包括误报)的总成本是否值得特定测试捕捉到的问题?
如果测试捕捉到的问题“昂贵”,那么您可以承担努力找出如何测试它并维护该测试的成本。如果测试捕捉到的问题微不足道,则编写(并维护!)该测试(即使在代码更改的情况下)也应该很简单。
单元测试的核心目标是保护开发人员免受实现错误的影响。这就表明过度努力将是一种浪费。在某个点之后,有更好的策略来获得正确的实现。此外,在某个点之后,用户可见的问题是由于正确实现了错误的事物,只能通过用户级别或集成测试来捕获。
你不会测试什么?任何可能不会出错的东西。
在代码覆盖率方面,您要目标是实际编写的100%代码 - 即您不需要测试第三方库代码或操作系统代码,因为该代码已经经过测试交付给您。除非它没有。在这种情况下,您可能需要测试它。或者如果已知存在错误,则可能要测试错误的存在,以便在修复错误时获得通知。
你可以设置一个测试数据库,从而实现数据访问。
通常,“无法测试”的内容是FTP、电子邮件等。然而,它们通常是框架类,可以依赖它们,因此如果将其隐藏在抽象层后,则不需要进行测试。
另外,仅有100%的代码覆盖率是不够的。
对于GUI界面的单元测试也是很困难的,虽然不是不可能,我想。
我实际上是使用一个假的SMTP服务器(Wiser)来进行电子邮件单元测试。这样可以确保您的应用程序代码正确:
http://maas-frensch.com/peter/2007/08/29/unittesting-e-mail-sending-using-spring/
其他服务器也可能有类似的做法,否则您应该能够模拟API...
顺便说一下:100%的覆盖率只是个开始...这只意味着所有代码已经被执行了一次....并没有考虑边缘情况等。