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)
Seth Vargo
Release Engineer, Opscode
@sethvargo
From: Ranjib Dey Ranjib Dey
Reply: chef@lists.opscode.com chef@lists.opscode.com
Date: January 1, 2014 at 2:50:04 PM
To: chef@lists.opscode.com chef@lists.opscode.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 eric.wolfe@marshall.edu 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
Phone: 304.942.3970
Email: eric.wolfe@marshall.edu
QOTD:
"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
if defined?(ChefSpec)
def create_yum_repository(resource_name)
ChefSpec::Matchers::ResourceMatcher.new(:yum_repository, :create, resource_name) # this is bare minimum, you can chain in the attributes too.
end
end
now you rule the world 
it "creates yum repository foo" do
expect(chef_run).to create_yum_repository(chef_run.node.yum.dell.community.repositoryid)
end
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 eric.wolfe@marshall.edu 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 sethvargo@getchef.com wrote:
As promised, I wrote a blog post about the new resource coverage reporter in ChefSpec: https://sethvargo.com/chef-recipe-code-coverage/.
Happy reading/cooking/testing!
Seth Vargo
Release Engineer, Opscode
@sethvargohttps://twitter.com/sethvargo
From: Seth Vargo Seth Vargomailto:sethvargo@getchef.com
Reply: Seth Vargo sethvargo@getchef.commailto:sethvargo@getchef.com
Date: December 29, 2013 at 2:57:10 PM
To: chef@lists.opscode.com chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: ChefSpec v3.1.0 hits the shelves
Ohai Chefs,
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.
Changeloghttps://github.com/sethvargo/chefspec/blob/master/CHANGELOG.md, Changesethttps://github.com/sethvargo/chefspec/compare/v3.0.2...master
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.
Seth Vargo
Release Engineer, Opscode
@sethvargohttps://twitter.com/sethvargo
