General discussion about Chef

[chef] Re: Re: Re: ChefSpec included recipe resources


Chronological Thread 
  • From: Yoshi Spendiff < >
  • To: chef < >
  • Subject: [chef] Re: Re: Re: ChefSpec included recipe resources
  • Date: Fri, 21 Aug 2015 10:57:17 -0700
Well I use the Berkshelf plug-in which does filtering based on the cookbook. The resources are declared in the same cookbook, but they're declared as a package not a yum_package, and I already check for the package resource in a different ChefSpec test in the same cookbook and testing run (which passes). So say I have the following recipes, for example:

cookbook/recipes/package.rb
package 'git'

cookbook/recipes/default.rb
include_recipe 'cookbook::package'

And the following tests (cut down for brevity):

specs/recipes/package_spec.rb
expect(chef_run).to install_package('git')

specs/recipes/default_spec.rb
expect(chef_run).to include_recipe('cookbook::package')

If I run rspec against these then I end up with the following missing resource even though I don't actually define it, and the test for the package resource passes.

untouched; yum_package[git]

This only happens if I test against the default recipe which does an include. If I test just the package recipe then the package resource and tests work fine. I'm guessing package calls yum_package under the hood but I don't know why it shows as a duplicate resource as the existing package resource.

The best way I've found so far to get around this for now is to stub out the include statement in the default recipe, as that's all the default recipe does. But this has problems as you need to stub out every call to include_recipe, not just selective ones, and all the test statements if including multiple recipes need to go in a single it block. Thus it's not a solution for many cases and I was wondering if there's a better one:

before do
  allow_any_instance_of(Chef::Recipe).to receive(:include_recipe).and_call_original
  %w(cookbook::package).each do |recipe|
    allow_any_instance_of(Chef::Recipe).to receive(:include_recipe).with(recipe)
  end
end

it 'includes recipe' do
  %w(cookbook::package).each do |recipe|
    expect_any_instance_of(Chef::Recipe).to receive(:include_recipe).with(recipe)
  end
  chef_run
end

Additional included recipes have to go in the arrays

On Fri, Aug 21, 2015 at 9:12 AM, Ranjib Dey < " target="_blank"> > wrote:
if you can keep your own recipes and external recipes in different locations, you can use chefspec's filter to include only your recipes for coverage calculation
hth
ranjib

On Thu, Aug 20, 2015 at 9:32 AM, Sean OMeara < " target="_blank"> > wrote:
ChefSpec just makes assertions about the compiled resource_collection.

Since include_recipe compiles the requested recipes, rewriting the specs for those is redundant.

This should be enough

Unfortunately, due to the way Chef works, you won't have %100 ChefSpec code coverage unless you go and restate yourself.

As for package vs yum_package, that's a Chef version specific detail, that ChefSpec can't really do much about.

-s


On Wed, Aug 19, 2015 at 8:09 PM, Yoshi Spendiff < " target="_blank"> > wrote:
Hi,

I have a cookbook that has a few recipes, so of them install packages using the package resource.

I have ChefSpec tests for each of these individual recipes that check that the package resource is doing something. All is well.

I also have a default recipe in this cookbook that includes some of the other recipes in the cookbook, including ones that have a package resource. In fact that's all that recipe does (include_recipe) so in my ChefSpec tests for that recipe I just check for the includes.

When looking at the code coverage reports from ChefSpec they're saying there's a bunch of yum_package resources that are not being touched, which match up to the package resources in the other recipes. At no place do I actually use a yum_package resource.

Why is this specifying yum_package instead of using the package resource and check? Can I make it not do this?





--

Archive powered by MHonArc 2.6.16.

§