[chef] Re: Re: Re: Re: ChefSpec v3.1.0 hits the shelves

["Eric G. Wolfe" < >]

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: 
 
 ">
 

QOTD:
	"I'm not really for apathy, but I'm not against it either..."

On 01/01/2014 04:44 AM, Ranjib Dey wrote:

" type="cite">

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 :-D

    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 < " target="_blank"> > 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 < "> > 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
@sethvargo<https://twitter.com/sethvargo>
________________________________
From: Seth Vargo Seth Vargo<mailto: "> >
Reply: Seth Vargo "> <mailto: "> >
Date: December 29, 2013 at 2:57:10 PM
To: "> "> <mailto: "> >
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.

Changelog<https://github.com/sethvargo/chefspec/blob/master/CHANGELOG.md>, Changeset<https://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šin<https://github.com/DracoAter> for incredibly faster tests if you don't need stubbing
  *   Support for Librarian courtesy of Mathias Lafeldt<https://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
@sethvargo<https://twitter.com/sethvargo>