spi*_*dal 33 language-agnostic tdd unit-testing testing-strategies
项目编写单元测试的哪些部分几乎或几乎不可能？数据访问？FTP？
如果对这个问题有答案,那么%100的报道就是一个神话,不是吗？
spi*_*dal 37
在这里,我发现(通过haefed Michael Feathers说的话可以回答:
他说,
在以下情况下,测试不是单元测试:
- 它与数据库进行对话
- 它通过网络进行通信
- 它触及文件系统
- 它不能与任何其他单元测试同时运行
- 您必须对您的环境执行特殊操作(例如编辑配置文件)才能运行它.
他在同一篇文章中再次提到:
通常,单元测试应该很小,它们测试方法或几种方法的相互作用.当您将数据库,套接字或文件系统访问权限提取到单元测试中时,它们不再是那些方法; 它们是关于将代码与其他软件集成的.
Kev*_*tle 13
100%的覆盖率是一个神话,它并不意味着80%的覆盖率是无用的.当然,目标是100%,在单元测试和集成测试之间,你可以接近它.
单元测试中不可能的是预测客户将对产品做的所有奇怪的事情.一旦你开始发现这些令人难以置信的代码转换,请确保将测试卷回到测试套件中.
目标不是100%的代码覆盖率,也不是80%的代码覆盖率.单元测试易于编写并不意味着您应该编写它,并且单元测试难以编写并不意味着您应该避免这种努力.
任何测试的目标都是以最友好的方式检测用户可见的问题.
测试标记的创作,维护和诊断问题(包括误报)的总成本是否值得特定测试捕获的问题？
如果测试捕获的问题是"昂贵的",那么你可以付出努力去弄清楚如何测试它,并保持测试.如果测试捕获的问题是微不足道的,那么编写(并维护!)测试(即使在代码更改的情况下)更好是微不足道的.
单元测试的核心目标是保护开发人员免受实现错误的影响.仅这一点就应该表明过多的努力将是一种浪费.在某一点之后,有更好的策略来获得正确的实施.此外,在某一点之后,用户可见的问题是由于正确实现了错误的东西,只能通过用户级别或集成测试来捕获.
| 归档时间： |
|
| 查看次数： |
5210 次 |
| 最近记录： |