2

上下文如下，我们有一个 MVC Web 应用程序，数据库中有很多遗留代码。（我们不允许将此代码迁移到服务器端）对于我们的持久性存储，我们使用存储库模式。

我们的客户想要向应用程序添加新功能，因此我们显然在服务器端添加了所有新业务逻辑。

我们现在遇到的问题是关于我们的功能测试套件，它每天运行的速度越来越慢。

主要原因是我们使用 selenium 从浏览器运行测试到数据库（端到端）。

我想知道人们是否成功地使用了以下其他策略：

1.摆脱用户界面

在控制器级别运行测试，而不必通过浏览器和 Web 服务器。为了弥补通过 UI 进行测试的损失，我们将编写 javascript 单元测试或 MVC 视图单元测试。

2.摆脱数据库

编写我们存储库的“InMemory”版本，以便应用程序可以完全在内存中运行，这也应该加快测试套件的速度，因为我们不会撞到磁盘和更少的网络。作为补偿，我们将为我们的数据库存储库编写集成测试。

我认为同时执行1+2 策略会产生最大的执行速度，我们将测试真正重要的东西（控制器、业务层、域实体和各种帮助程序作为一个整体）（我认为 UI 和数据库是“细节” ”）。

现在，问题在于，事实上，由于数据库有很多遗留代码，我不知道仅仅依赖于这些东西的集成测试并将数据库排除在功能测试套件之外是否足够安全。我应该把它留在套房里吗？还是很好？

任何经验或建议将不胜感激！

我的一些发现如下：

  • 持续交付书建议这些测试应该始终是端到端的，即使它们很慢（尽管他们也说不是每个人都会同意这一点）
  • 据我了解，鲍勃叔叔会同意 1+2 策略，但我不确定他是否会认为使用带有遗留代码的数据库。
4

1 回答 1

2

测试的持续时间越来越长是主要问题。最终它会增长到你必须放弃一些测试的地步。那是一个滑坡。

为了防止这种情况发生，我当然会采取 1+2 的策略，但我也会保持一定数量的端到端测试。

随着您添加越来越多的绕过 UI 和 DB 的测试，您可以开始决定哪些端到端测试是多余的，哪些是测试系统连接正确所必需的。

最后，如果端到端测试是纯粹的管道测试，目标是使用 1+2 策略测试所有业务规则和表示行为。

您的存储过程很复杂。只要您不是数据库代码的更多功能，您就可以管理它。事实上，如果你能逐渐用服务器代码替换一些数据库代码，你会做得更好。一些数据库代码可以在系统的其余部分不存在的情况下进行测试。并且可以模拟一些数据库行为。不幸的是，也可能存在只能端到端测试的行为，因此只要存在遗留数据库代码，您就可能不得不保留这些测试。

这里最重要的因素是慢慢来，避免倒退。不要着手一个巨大的项目来“修复测试”。而是逐步进行渐进式改进。练习“童子军规则”，总是让测试比你找到的更好。永远不要让他们变得更糟。一点一点地，将越来越多的测试转移到策略 1+2 中。一点一点地替换那些你觉得替换的存储过程。逐渐消除最冗余的端到端测试。

于 2012-10-05T14:10:42.040 回答