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, Changeset

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 for incredibly faster tests if you don’t need stubbing
Support for Librarian courtesy of Mathias Lafeldt
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

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
From: Seth Vargo Seth Vargo
Reply: Seth Vargo sethvargo@getchef.com
Date: December 29, 2013 at 2:57:10 PM
To: chef@lists.opscode.com 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.

Changelog, Changeset

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 for incredibly faster tests if you don’t need stubbing
Support for Librarian courtesy of Mathias Lafeldt
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

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

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

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.eduwrote:

I played around with this today on my yum-dell (
GitHub - atomic-penguin/cookbook-yum-dell: Configures Dell yum repositories, and installs OMSA) 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: Chef recipe code coverage | Seth Vargo.

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.com<mailto:
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šin<
    DracoAter (Juri Timošin) · GitHub> for incredibly faster tests if you don't
    need stubbing
  • Support for Librarian courtesy of Mathias Lafeldt<
    mlafeldt (Mathias Lafeldt) · GitHub>

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

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

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

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
<http://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>

On Wed, 01 Jan 2014 13:41:50 -0500 "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.

Without looking at your code (not in work-mode yet), why do you check
for a template? Shouldn't the check be just for the existance of a file
with a certain content? No matter if it comes from a cookbook_file,
template or remote_file?

For example
expect(chef_run).to
render_file('/etc/munin/munin.conf').with_content(/generated by
Chef/)
doesn't depend on the kind of resource creating the file (from my
branches for the munin cookbook). Still it checks for the content.

Have fun,

Arnold

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

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.eduwrote:

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

 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.eduwrote:

I played around with this today on my yum-dell (
GitHub - atomic-penguin/cookbook-yum-dell: Configures Dell yum repositories, and installs OMSA) 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: Chef recipe code coverage | Seth Vargo.

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.com<mailto:
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šin<
    DracoAter (Juri Timošin) · GitHub> for incredibly faster tests if you don't
    need stubbing
  • Support for Librarian courtesy of Mathias Lafeldt<
    mlafeldt (Mathias Lafeldt) · GitHub>

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

Eric, you can package the custom matcher with the cookbook by putting it in the “libraries” directory. There are instructions in the README.
Seth Vargo
Release Engineer, Opscode
@sethvargo
From: Eric G. Wolfe Eric G. Wolfe
Reply: chef@lists.opscode.com chef@lists.opscode.com
Date: January 1, 2014 at 1:42:02 PM
To: chef@lists.opscode.com chef@lists.opscode.com
Subject: [chef] Re: Re: Re: Re: ChefSpec v3.1.0 hits the shelves
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 :smiley:

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

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

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

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