用于验证属性或配置的单元/集成测试

Question

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

这些配置中的许多配置都会导致运行时行为，即使它们被底层库或框架使用也是如此。验证配置是否在运行时正确使用是否是一个明智的想法？

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

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

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

Answer 1

没有。单元测试将告诉您什么在测试工具中有效，哪些是 - 并且应该与生产中的不同。

当你说要验证配置时，你会碰到头上的钉子。测试和验证是两个完全不同的事情。如果您有办法验证生产中的运行时配置，它还可以帮助您诊断运行时错误行为。

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

配置问题通常是全有或全无的;如果你没有得到恰到好处的配置，没有任何反应，你也不知道为什么。 （对于函数式编程尤其如此。）日志记录不仅可以告诉您配置是什么，还可以告诉您配置失败的时刻。

还有其他一些聪明的方法可以将配置细节洒入运行时。例如，将详细的运行时详细信息附加到错误消息，尤其是电子邮件，其中您有更多空间而不是日志。或者是一种调试模式，其中悬停在UI元素上会告诉您关于该元素的类和其他事实。

集成测试（组件在插接时工作）和冒烟测试（某些完整配置正确）可能很重要 - 如果部署，我认为有必要没有手动测试 - 但它们不能代替运行时验证。

Answer 2

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

  

配置在运行时正确使用

Orchard收件人也被搞砸了很多次。这是Docker containers的重点。测试产品/服务所使用的基础架构及其配置非常简单。我已成功使用serverspec。