【问题标题】:Unit testing a Chef provider对 Chef 提供者进行单元测试
【发布时间】:2014-02-02 02:55:14
【问题描述】:

如何为 Chef 提供者编写单元测试?

到目前为止,我们的单元测试策略使用ChefSpec 作为配方,并且我们将大部分有趣的逻辑填充到库中,以使逻辑更易于测试。但是,我们仍然会遇到我们的提供者调用其他资源的问题(以及其他简单的逻辑问题)。例如:

action :run do

   helper = Helper.new
   template '/etc/hosts' do
     source 'hosts.erb'
     variables ({
              "host" => @new_resource.host,
              "ip_address" => node['ipaddress']
          })
     only_if { helper.update_hosts }
   end

   service 'httpd' do
      action :restart
   end
end

(这不是真正的代码,只是一个简单的例子)

我们想做的是单独测试此提供程序以检查逻辑错误。 ChefSpec 具有进入 LWRP 的能力,但看起来这会迫使我们将 LWRP 放入食谱中,而且我们的许多食谱基本上都是没有食谱的 LWRP 库。我们还希望在测试中保持清晰的分离,因此通过查看文件名很明显哪个组件失败了。

此外,如果 LWRP 定义中有任何语法错误,测试会自动失败,那将是很好的选择。例如:

action :run do
   template '/etc/hosts/' do
     source_whoops 'hosts.erb'
     action :whoops
   end
end

如果上面的语句由于属性名称定义错误而导致测试失败,并且动作名称不存在(就像 ChefSpec),那就太好了。

我想出的唯一解决方案基本上是创建一个“测试食谱”——一个单独的食谱,它用一个食谱定义每个 LWRP 1:1,因此 ChefSpec 可以通过这种方式介入。这似乎是一个合理但不太理想的解决方案。

【问题讨论】:

    标签: unit-testing chef-infra chefspec


    【解决方案1】:

    看起来有一个(最近的)解决方案。

    首先,this pull request 基本上可以满足我的要求,尽管 ChefSpec 维护者出于可以理解的原因拒绝了它。

    维护者建议使用 mycookbook_test 模式 - 一个单独的说明书保存所有的单元测试。这将允许一个简单的 1 recipe-per-lwrp 方法。

    此外,这种方法使食谱远离任何单元测试,这对食谱的消费者来说是件好事。消费者可能想要运行他们自己的单元测试,并且没有必要(或希望)在第三方食谱上运行测试。

    【讨论】:

    • 是的。这正是我所说的:)
    猜你喜欢
    • 1970-01-01
    • 2023-01-10
    • 2021-11-24
    • 1970-01-01
    • 1970-01-01
    • 2020-05-01
    • 2017-06-18
    • 2017-08-23
    • 2017-02-02
    相关资源
    最近更新 更多