单元测试第三方ORM

Question

我已经阅读了关于单元测试各种应用程序的有用性的几个主题。这些意见可以从“一直测试所有事情”到“​​单元测试无用”，以及其间的所有内容（“测试有意义的测试”）。我倾向于向中间倾斜。

这使我想到我的问题。我想，以决定是否将是有益的或实用的有一些基本的单元测试测试的第三方ORM的建议在这种SO帖子： link text

一些基准测试可以作为对未来的重大更改保险有用，这取决于你如何使用该工具。例如，不是模拟整个n层链（我不是在不需要的时候嘲笑），只需使用ORM工具来创建，读取，更新和删除一个典型的对象/记录，并且使用（测试）数据库上的直接SQL语句验证操作。这样，如果第三方供应商稍后更新了某些会破坏其基本功能的内容，并且项目的新开发人员可以很容易地看到如何使用单元测试示例中的ORM工具。

我的主要保留下面这个建议是，它需要太多的设置，将是一个头痛要维护，总而言之，它不会在我们的环境中实际。下面是一些点的总结考虑：

1. 我们正在使用的ORM需要创建和其数据访问层注册，并通过身份验证的用户相关联的静态数据源对象（S）。这需要大量的测试设置，并且在没有用户登录的构建服务器上可能会出现问题。
2. ORM供应商在发布新更新和不打破基本功能方面拥有相当不错的记录。此外，无论何时何时将ORM更新至最新版本，我都会想到该应用程序不会直接进入生产环境，但是无论如何都会进行彻底的回归测试。
3. 在这种环境下维护单元测试的测试数据库是有问题的。在每个主要发行版之后，测试数据库将被清除，并使用混淆了敏感数据的分段替换数据库备份。我会想象为了有ORM单元测试的测试数据库，我们需要运行一些脚本/代码来将数据库设置为“测试”状态。再次设置和维护太多。
4. 最后ORM文档/帮助新开发人员。我可以看到这样的事情可能会有用。但是，ORM供应商提供了相当不错的文档/帮助演示应用程序。所以编写单元测试似乎并不值得所有的努力。

那么，为了确保ORM完成它应该做的事情（这是CRUD），是否值得去解决所有这些问题？无论如何，它不应该是供应商的责任吗？

Answer 1

你自己说过。测试它有意义的地方。如果它会让你“感觉”更好地测试第三方ORM，那就去做吧。但是，最终，你会信任他们的工具。如果ORM突然停止工作，你会怎么做？你有没有编写足够的代码来防止它被你轻易地撕掉？你可能会等他们解决它。

基本上，你必须把第三方工具当作俗话说的黑匣子，让他们做你买他们做的事情。那是你付了钱的原因，对吧？不要自己写这个。

Answer 2

在这个特殊情况下，我不打扰。我认为你在这里承担了一个糟糕的投资回报是正确的。

是的，我认为这是供应商的责任。我期望（并承担）他们的东西的作品。这就是我对待我的供应商的方式。

Answer 3

供应商有责任确保ORM完成它应该做的事情，但是您有责任确保您的应用程序完成它应该做的事情，并且如果它因任何原因失败，您的客户将会即使它是“正义的”，因为ORM失败，也会不高兴。

您的测试可以确保ORM的工作方式与您期望的那样按照您调用它的方式工作。有可能ORM会以一种不“破碎”的方式进行更改，但与您的应用程序无法很好地协作。这就是说，如果你对ORM充满信心，并且认为设置和维护ORM的任何一种自动化测试都不值得花费精力，那很可能不是，特别是如果你有其他级别的话如果出现问题，可能会发现问题。

Answer 4

我个人认为真正的单元测试应该只测试应用程序本身，并且需要单独部署和配置的所有东西都应该被模拟出来。

你在说什么是编写一些集成/功能测试，测试整个系统的端到端。这些永远不会是轻量级的，但在某些情况下可能仍然有用（例如，如果您的系统变化不大并且同时对您的公司至关重要）。我也看到了这样的测试，使用虚拟服务器（VMWare或Microsoft等效软件）以及在每次测试运行前从文件恢复的示例数据库。您也可以只设置一次ORM，并接受测试失败，主要是因为配置会中断。显然你可以测试更多，但要注意成本更高。

Answer 5

测试第三方ORM库的工作完全不是单元测试。但是，这不是你问题的关键。正如在Michael Feathers撰写的“工作有效地使用遗留代码”或Eric Evans的“Domain-Driven Design”或Robert Martin的“Clean Code”等书中所说的，您的第三方ORM库是一项技术应该从您的代码库中抽象出来的细节，正是因为您根据定义无法控制第三方库。如果他们改变，你可以容纳。

所以你的解决方案是围绕这个ORM库做一个包装，理想地将与域相关的接口发布到应用程序的其余部分，但通用接口也可能会这样做。您需要使用完整堆栈自动化测试来测试这个包装，这必然会将您的应用程序与数据库以及所需的所有配置和准备一起设置。这个测试不是单元级的，预计会很慢。

您可以在Paul M. Duvall的书“持续集成”第6章中了解不同级别的测试以及它们应该如何设置。

当为应用程序级别编写真正的单元级别测试时，可以将包装器模拟到ORM库上方，因为您控制包装器的代码，因此您可以执行此操作。

这是一个标准做法。它的明显好处是，当您决定更新ORM库时（或者极有可能），当您的客户/老板决定切换到另一个ORM不兼容的ORM或数据库时，您将获得关于ORM库的即时反馈你的包装测试中的回归错误以及你需要做的所有事情都是为了适应包装内的变化。顺便说一句，“过多的维护负担”是缺乏自动化造成的谬误。