什么不测试单元测试？

项目编写单元测试的哪些部分几乎或几乎不可能？数据访问？FTP？

如果对这个问题有答案,那么%100的报道就是一个神话,不是吗？

在这里,我发现(通过haefed Michael Feathers说的话可以回答:

他说,

在以下情况下,测试不是单元测试:

它与数据库进行对话

它通过网络进行通信

它触及文件系统

它不能与任何其他单元测试同时运行

您必须对您的环境执行特殊操作(例如编辑配置文件)才能运行它.

他在同一篇文章中再次提到:

通常,单元测试应该很小,它们测试方法或几种方法的相互作用.当您将数据库,套接字或文件系统访问权限提取到单元测试中时,它们不再是那些方法; 它们是关于将代码与其他软件集成的.

100%的覆盖率是一个神话,它并不意味着80%的覆盖率是无用的.当然,目标是100%,在单元测试和集成测试之间,你可以接近它.

单元测试中不可能的是预测客户将对产品做的所有奇怪的事情.一旦你开始发现这些令人难以置信的代码转换,请确保将测试卷回到测试套件中.

实现100%的代码覆盖几乎总是浪费.有很多资源.

单元测试没有什么是不可能的,但总有收益递减.单元测试单元测试可能不值得.

目标不是100%的代码覆盖率,也不是80%的代码覆盖率.单元测试易于编写并不意味着您应该编写它,并且单元测试难以编写并不意味着您应该避免这种努力.

任何测试的目标都是以最友好的方式检测用户可见的问题.

测试标记的创作,维护和诊断问题(包括误报)的总成本是否值得特定测试捕获的问题？

如果测试捕获的问题是"昂贵的",那么你可以付出努力去弄清楚如何测试它,并保持测试.如果测试捕获的问题是微不足道的,那么编写(并维护!)测试(即使在代码更改的情况下)更好是微不足道的.

单元测试的核心目标是保护开发人员免受实现错误的影响.仅这一点就应该表明过多的努力将是一种浪费.在某一点之后,有更好的策略来获得正确的实施.此外,在某一点之后,用户可见的问题是由于正确实现了错误的东西,只能通过用户级别或集成测试来捕获.