验证属性或配置的单元/集成测试答案

【问题标题】：Unit/integration tests that verify the properties or configurations验证属性或配置的单元/集成测试
【发布时间】：2016-08-24 14:27:09
【问题描述】：

编写单元/集成测试来验证属性或配置是否有意义，因为任何中等到高度复杂的应用程序都包含大量配置（通过 YAML 或属性文件）？

其中许多配置派生出运行时行为，即使它们被底层库或框架使用。在运行时验证配置是否正确使用是一个明智的想法吗？

一个赞成的论点是，由于没有编译器安全性，我们需要以某种方式验证配置是否正确地指示了行为。

con 参数是，我们是否正在验证底层框架的实现？

仅测试配置文件可能还不够，因为它不能保证配置是否会在运行时正确使用（可能存在拼写错误或其他类似错误）。

【问题讨论】：

【解决方案1】：

没有。单元测试会告诉您测试工具中的工作原理是什么，并且应该与生产环境中的不同。

当您说要验证配置时，您一针见血。测试和验证是完全不同的两件事。如果您有办法在生产环境中验证运行时配置，它还可以帮助您诊断运行时不当行为。

有很多方法可以验证运行时配置。最简单和最好的方法是记录（例如“2016-09-24 10:13:00 连接到http://my-configured-server.example.com 以获取用户令牌”）。不要只是将配置转储到日志文件中——这不是端到端验证——将配置详细信息散布到日志消息中。

配置问题通常是全有或全无；如果你没有得到正确的配置，什么都不会发生，你也不知道为什么。（函数式编程尤其如此。）日志记录不仅可以告诉您配置是什么，还可以告诉您配置失败的时间。

还有其他巧妙的方法可以将配置细节添加到运行时中。例如，将详细的运行时详细信息附加到错误消息中，尤其是您的空间比日志更多的电子邮件。或者在调试模式下，将鼠标悬停在 UI 元素上会告诉您有关该元素的类和其他事实。

集成测试（组件在插入在一起时工作）和冒烟测试（一些完整的配置确实正确）可能很重要 - 如果您部署，我会说有必要无需手动测试——但它们不能替代运行时验证。

【讨论】：

根据我们讨论的配置，在部署到生产后立即运行的自动化功能冒烟测试可以“间接”告诉您配置是正确的，因为系统可以执行关键用例而无需错误。
好点，毛里。测试应该回答“你应该害怕什么？”这个问题。如果您签入版本控制的更改可能会触发部署中断，那么您需要找到一种方法来测试它——因为您应该对此感到害怕。如果在您的部署过程中有一个手动步骤，某人（例如测试工程师）会立即注意到代码无法运行，那么添加冒烟测试是可选的，因为您最担心的是尴尬。

【解决方案2】：

恕我直言，这是非常合理的，尤其是在谈论不断增长的虚拟化时。在我之前参与的一个项目中 - 一个 mSOA 平台，它轻松支持（当时）数百个网站，我们发现大多数问题正是由于

在运行时正确使用配置

Orchard 收据也经常搞砸。所以给Docker containers一点。测试您的产品/服务正在使用的基础设施及其配置非常简单。我已经成功使用serverspec。

【讨论】：