单元测试第三方ORM

Question

我已经在SO上阅读了一些关于单元测试各种应用程序的有用性的线程。意见的范围可以从“一直测试所有内容”到“单元测试无用”，以及介于两者之间的所有内容（“测试哪里有意义”）。我倾向于向中间倾斜。

这引出了我的问题。我正在尝试根据此SO帖子的建议，确定测试第三方ORM的基本单元测试是否有益或实用： link text

  

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

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

1. 我们正在使用的ORM要求创建静态数据源对象并将其注册到其数据访问层并与经过身份验证的用户关联。这将需要大量的测试设置，并且可能在没有用户登录的构建服务器上存在问题。
2. ORM供应商在发布新更新和不破坏基本功能方面有着良好的记录。此外，无论什么时候将ORM更新到最新版本，我都会想象应用程序不会直接用于生产，但无论如何都会进行彻底的回归测试。
3. 在此环境中维护用于单元测试的测试数据库是一个问题。测试数据库在每次主要版本发布后都会被清除，并且会使用混淆了敏感数据的分段替换为db backup。我想，为了有一个用于ORM单元测试的测试数据库，我们需要运行一些将数据库设置为“测试”状态的脚本/代码。再次进行过多的设置和维护。
4. 最后是新开发人员的ORM文档/帮助。我可以看到这样的东西是如何有用的。但ORM供应商提供了非常好的文档/帮助演示应用程序。因此，编写单元测试似乎并不值得所有的努力。

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

Answer 1

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

基本上，你必须将第三方工具视为众所周知的黑匣子，并让他们做你买它们要做的事情。这就是你付出钱的原因，对吧？不必自己写。

Answer 2

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

是的，我认为这是供应商的责任。我希望（并假设）他们的东西有效。这就是我对待供应商的方式。

Answer 3

供应商有责任确保ORM完成它应该做的事情，但是您有责任确保您的应用程序能够完成它应该做的事情，如果它因任何原因失败，您的客户将是不开心，即使它是“正义”，因为ORM失败了。

您的测试可以确保ORM以您预期的方式工作，就像您调用它一样。 ORM可能会以一种不“破坏”的方式改变，但这种方式与您的应用程序无关。

话虽如此，如果你对ORM充满信心，并认为设置和维护ORM的任何类型的自动化测试都不值得付出努力，那么可能不会，特别是如果你有其他级别的如果出现问题可能会发现问题的测试。

Answer 4

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

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

Answer 5

测试第三方ORM库是否完成其工作根本不是单元测试。但是，这不是你问题的重点。

正如在Michael Feathers的“有效地使用遗产代码”或Eric Evans的“Domain-Driven Design”或Robert Martin的“清洁代码”这样的书中所说的多次，你的第三方ORM库是一个技术细节应该从代码库中抽象出来，正是因为根据定义你无法控制第三方库。如果他们改变了，你可以适应。

因此，您的解决方案是围绕此ORM库创建一个包装器，将理想的域相关接口发布到应用程序的其余部分，但通用接口也可能会这样做。您需要使用fullstack自动化测试来测试此包装器，这不可避免地应用程序以及数据库及其所需的所有配置和准备。这个测试不是单元级的，预计会非常慢。

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

在为应用程序级别编写真正的单元级测试时，您可以模拟ORM库上方的包装器，您可以这样做，因为您可以控制包装器的代码。

这是一种标准做法。它的明显好处是，当您决定更新ORM库或（当您的客户/老板决定切换到此ORM不兼容的另一个ORM或数据库时）（您很可能），您将获得有关的即时反馈来自包装器测试的回归错误，您需要做的就是适应包装器内的更改。

顺便说一下，“太多的维护负担”是缺乏自动化造成的谬误。