为开发以外的环境编写测试是个好主意吗？

Question

假设我有一套（相当典型的）环境：PROD, UAT, QA, DEV。在所有环境中运行测试是一个好主意吗？

这就是我的想法。我在SQL中有一个我的代码所依赖的proc，我称之为proc_getActiveCustomers。如果该proc不存在，我的应用程序将快速向南移动。所以我编写了一个测试，检查数据库中是否存在此proc。这里没什么新鲜的。

但是当我将我的应用程序部署到QA环境时，我是否还想要一个测试来检查该环境是否存在proc_getActiveCustomers？我认为这是一个好主意，但我从未听说过在开发之外的环境中进行测试。让我想知道是否有一些我不知道的缺点。

我要走的方向是在代码中有一个环境列表，然后将该环境传递给我的单元测试。

Answer 1

这称为smoketest，恕我直言，你的情况也是个好主意。

冒烟测试是一种快速（一组）测试，以确保产品安装正确并且基本上似乎处于工作状态。与集成，负载等测试相比，这些测试更彻底，消耗资源，并且经常以不合需要的方式改变系统状态，因此不适合生产环境。

Answer 2

您正在谈论的测试对我来说似乎不是一个“单元”测试。它会检查您的设置是否正确。我肯定会在应用程序初始化代码中包含检查并使其创建存储过程以防万一，但我不会在TDD意义上将其称为“测试”。

就像运行清单一样，看看是否所有组件都安装正确。

单元测试应该检查组件是否按预期工作，而不是在那里......

Answer 3

您的驱动应该是让应用程序进入可部署的情况。我会说一切都模拟了一个生产环境。如果您的应用具有此依赖关系（真实，模拟，子网或伪造），则应始终对其进行测试。您可能想要查看持续集成。它可能会帮助您描述是否需要此测试。