Ranjib is right - I wrote an entire blog post on the subject a few months ago:
Higher-level testing frameworks (like Test Kitchen) will handle the “integration” of all the pieces (hence why it’s an integration testing framework)
Release Engineer, Opscode
From: Ranjib Dey Ranjib Dey
Reply: firstname.lastname@example.org email@example.com
Date: January 1, 2014 at 2:50:04 PM
To: firstname.lastname@example.org email@example.com
Subject: [chef] Re: Re: Re: Re: Re: ChefSpec v3.1.0 hits the shelves
its bad only because its beyond your code’s responsibilities. you have not written the provider, why you want unit test it? your recipe defines a yum_repo resource, with certain attributes, ideally you would only like to check if the resource is there,with the expected attributes. if you are adding that resource conditionally, testing that branching can be part of your specs. if you are wrapping the yum_repository inside another lwrp, you may step inside that lwrp and test it. but lwrp implementation is beyond your code’s boundary. those render_file assertion should be done on the yum cookbook. again, there is no harm, its just my opinion
yeah ideally the matchers should come from the parent lwrp cookbook,
On Wed, Jan 1, 2014 at 10:41 AM, Eric G. Wolfe firstname.lastname@example.org wrote:
Well, the whole point of asserting against a template was to sanity check the content, so I don’t see how that is bad. Of course, given the provider changes to file, rather than template, I should expect it to fail.
I did figure out the custom_matcher thanks to your clue, and the example here: https://github.com/sethvargo/chefspec/tree/master/examples/custom_matcher For others, who are curious about doing this.
Would the ideal scenario be shipping this custom_matcher with the parent LWRP cookbook for children consumers of that LWRP? Or should that custom matcher be redefined in each child cookbook that consumes a given LWRP?
Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems
Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
"I’m not really for apathy, but I’m not against it either…"
On 01/01/2014 04:44 AM, Ranjib Dey wrote:
its not doing something wrong. you are not really asserting against the the yum_repo, the step_into: [‘yum_repository’] declaration informs chefspec runner to evaluate the provider, as a result you obtain the templates, and then in your spec you are asserting against the template. this is good, but again, you are asserting against the resulting template not the yum_repository resource. its good, and its bad. if the yum_repository implementation changes the provider to use file instead of template , your specs will fail. … anyway thats not the point of discussion, to assert against that resource you need a matcher first.
chefspec example for defining a custom matcher
ChefSpec::Matchers::ResourceMatcher.new(:yum_repository, :create, resource_name) # this is bare minimum, you can chain in the attributes too.
now you rule the world
it "creates yum repository foo" do
and then you’ll see chefspec is reporting the resource as touched. also now you dont have to worry about yum_repository is implemented. the template rendering and lwrp provider evaluation is also important, but i think that should be placed inside the lwrp’s cookbook itself.
p.s currently its reporting the dependency cookbook’s coverage as well, use the filter feature to get a more accurate resource coverag.
happy new year
On Tue, Dec 31, 2013 at 11:13 PM, Wolfe, Eric G email@example.com wrote:
I played around with this today on my yum-dell (https://github.com/atomic-penguin/cookbook-yum-dell) cookbook that I have been working on since the yum 3.0 release.
It doesn’t seem to be recognizing consumed LWRP resources touched by tests. Am I missing some magic syntax keyword, or is that by design/necessity?
Seth Vargo firstname.lastname@example.org wrote:
As promised, I wrote a blog post about the new resource coverage reporter in ChefSpec: https://sethvargo.com/chef-recipe-code-coverage/.
Release Engineer, Opscode
From: Seth Vargo Seth Vargomailto:email@example.com
Reply: Seth Vargo firstname.lastname@example.org:email@example.com
Date: December 29, 2013 at 2:57:10 PM
To: firstname.lastname@example.org email@example.com:firstname.lastname@example.org
Subject: ChefSpec v3.1.0 hits the shelves
I’m happy to announce that I just released ChefSpec v3.1.0. The beta has been out for 2 weeks and users have reported very little problems. I made a few tiny documentation updates and improved the DSL for interacting with the Chef Server.
You can install ChefSpec 3.1.0 by running:
gem install chefspec --version 3.1.0
Or by updating the version in your Gemfile:
gem ‘chefspec’, ‘~> 3.1.0’
ChefSpec v3.1.0 builds upon the 3.0.0 series with amazing new features like:
- Converging against a “real” Chef Server (Chef Zero) (no need to use Chef Solo)
- Resource reporting! It’s finally here! Although still in primitive stages, ChefSpec v3.1.0 performs recipe analysis and generates a resource coverage report - perfect for testing you’ve hit all logic branches in your recipes
- (Advanced) Cacheable runner courtesy of Juri Timošinhttps://github.com/DracoAter for incredibly faster tests if you don’t need stubbing
- Support for Librarian courtesy of Mathias Lafeldthttps://github.com/mlafeldt
Things that are likely to break:
- The deprecations module is no longer included by default. If you have not yet upgraded from ChefSpec v2.x, you can manually include the module by adding require ‘chefspec/deprecations’ to the top of your spec_helper.
- The API for creating a node changed slightly between the last beta and this final release.
There are some really cool nerdy things happening under the hood, so I encourage you to look at the full diff :).
Look for an upcoming blog series on sethvargo.com about resource reporting (coverage) and chef server mode.
Join #chefspec on IRC on freenode
If you have blog posts, publications, or case studies for ChefSpec, please ping me.
Release Engineer, Opscode