您是否认为单元测试(以及测试驱动开发)必须在任何情况下完成,或者是否存在一些例外情况.我最近一直致力于项目类型,我无法看到单元测试如何有用或改进设计,代码质量等.一种类型的项目是PDF报告生成器,它采用聚合数据(已计算的值和QAed)并将其输出到PDF报告文件.另一种类型是使用第三方ORM工具的直接CRUD应用程序.我可以看到有人可以为使用CRUD应用程序的单元测试做出争论,但这是一个不必要的和耗时的设置工作,比如捅掉所有对数据库的调用和模拟业务对象等等.你需要知道数据库是否发生了什么事.
谢谢
请不要将作为工具的单元测试(UT)与测试驱动设计(TDD)混淆,后者是一种方法.看到这个更多
此外,请记住,单元测试的好处之一是用于回归测试,即作为针对未来重大变更的保险(并帮助验证修复的错误不会变得不固定).
在您的第一个示例中,我将对PDF转换进行单元测试,如下所示:
从一组已知的样本数据开始,然后生成PDF文档
手动验证生成的PDF是否正确
保留示例数据并将PDF文档更正为测试套件的一部分
编写一个函数来比较两个PDF文档的差异(在二进制或内容级别,视情况而定)
自动执行此单元测试,以将从样本数据生成的PDF文档与第一步中经过验证的文档进行比较
现在,每当您更改PDF生成代码时,您都会进行自动单元测试,以验证您是否至少因示例数据和输出格式而无法中断文档生成.
我使用相同的技术来验证HTML呈现的页面,GUI屏幕等.手动验证基线,然后自动进行比较.这为未来的重大变革提供保险.
当然,如果您的输出格式经常更改,这可能没那么有用,但基本输出格式的基线测试可能会有很长的使用寿命.
在你的第二个例子中,听起来你会测试第三方ORM工具,这可能毫无意义.但是,根据您使用该工具的方式,一些基线测试可能有助于防范未来的重大变更.例如,不是模拟整个n层链(我不是在没有必要时嘲笑的粉丝),只需使用ORM工具来创建,读取,更新和删除典型的对象/记录,使用(测试)数据库上的直接SQL语句验证操作.这样,如果第三方供应商稍后更新了破坏您将了解的基本功能的内容,并且项目的新开发人员可以轻松地了解如何使用单元测试示例中的ORM工具.
它通常主要取决于计划约束以及您将如何处理代码.如果你正在写一次性(很多人认为不存在),我认为不需要进行单元测试.
但是,如果您正在编写将来可能会重复使用或重新考虑的模块化软件 - 单元测试非常有用.
我经常发现它们的主要目的不是确定当前实现中的错误,而是确保在更改到达时不会引入错误.
我从来没有真正遇到过单元测试应用程序视图层的策略,这个策略值得一试.
不过,我喜欢有人证明我错了.
用Jeff&Joel最近对SOB的评论来解释:当你为产品增加价值时,你应该进行单元测试.
在您描述的两种情况下,您将能够以与编写单元测试相同的成本执行全部临时修复(和/或事后回归测试).所以不要编写单元测试.
"...这是一个不必要的和耗时的设置工作,比如刺破所有对数据库的调用和模拟业务对象等等,最后你需要知道数据库发生了什么."
听起来你在测试错误的东西.
为什么要删除数据库调用？为什么不创建一个测试数据库并测试针对该测试数据库的实际数据库调用？[这就是Django测试服务器的工作方式,它很棒.]
为什么要模拟业务对象？这就是你正在测试的,对吗？可以说"我们假设ORM有效",并声明您的"单位"是业务对象+ ORM +数据库.测试一下,因为问题就出现了.
单元测试你写的东西.
您下载的内容应该有自己的单元测试.
单元测试可以分层次进行 - 您可以编写类似集成的测试,假设ORM层已经通过了所有测试.
京公网安备 11010802040832号 | 京ICP备19059560号-6 