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
end
Additional included recipes have to go in the arrays
On Fri, Aug 21, 2015 at 9:12 AM, Ranjib Dey dey.ranjib@gmail.com 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 someara@chef.io 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
https://github.com/sethvargo/chefspec/blob/master/examples/include_recipe/spec/default_spec.rb
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 <
yoshi.spendiff@indochino.com> 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?
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com