单元测试第三方ORM

我已经阅读了关于单元测试各种应用程序的有用性的一些线程.意见的范围可以从"始终测试所有内容"到"单元测试无用",以及介于两者之间的所有内容("测试哪里有意义").我倾向于向中间倾斜.

这引出了我的问题.我正在尝试根据此SO帖子中的建议来确定测试第三方ORM的基本单元测试是否有益或实用: 链接文本

根据您使用该工具的方式,某些基线测试可能有助于防范未来的重大变更.例如,不是模拟整个n层链(我不是在没有必要时嘲笑的粉丝),只需使用ORM工具来创建,读取,更新和删除典型的对象/记录,使用(测试)数据库上的直接SQL语句验证操作.这样,如果第三方供应商稍后更新了破坏您将了解的基本功能的内容,并且项目的新开发人员可以轻松地了解如何使用单元测试示例中的ORM工具.

根据这个建议,我的主要保留意见是它需要太多的设置,维护是一件令人头痛的问题,而且在我们的环境中这一点都不实用.以下是要考虑的一些要点的摘要:

我们使用的ORM要求创建静态数据源对象并将其注册到其数据访问层并与经过身份验证的用户关联.这将需要大量的测试设置,并且可能在没有用户登录的构建服务器上存在问题.

ORM供应商在发布新更新和不破坏基本功能方面有着良好的记录.此外,无论什么时候将ORM更新到最新版本,我都会想象应用程序不会直接用于生产,但无论如何都会进行彻底的回归测试.

在这种环境中维护用于单元测试的测试数据库是有问题的.测试数据库在每个主要版本发布后都会被清除,并且会使用混淆了敏感数据的分段替换为db backup.我想,为了有一个用于ORM单元测试的测试数据库,我们需要运行一些将数据库设置为"测试"状态的脚本/代码.再次设置和维护太多.

最后是新开发人员的ORM文档/帮助.我可以看到这样的东西是如何有用的.但ORM供应商提供了非常好的文档/帮助演示应用程序.因此,编写单元测试似乎并不值得所有的努力.

那么,是否值得通过所有这些麻烦来确保ORM做它应该做的事情(这是CRUD)？这不应该是供应商的责任吗？

你自己说的.测试哪里有意义.如果它能让你"感觉"更好地测试第三方ORM,那就去做吧.但是,最终,你会信任他们的工具.如果ORM突然停止工作,你打算做什么？你有没有写过足够的代码来反对它,你不能轻易撕掉它？你可能会等他们修理它.

基本上,你必须把第三方工具当作众所周知的黑匣子,然后让它们做你买它们要做的事情.这就是你付出钱的原因,对吧？不必自己写.