ChefSpec 3.0


#1

Ohai Chefs!

I just released chefspec-3.0.0.beta.1, which is a major refactor of the code base with a focus on documentation, extensibility, and modularity. The full CHANGELOG can be found at https://github.com/acrmp/chefspec/blob/master/CHANGELOG.md#300-tbd. (I highly discourage looking at the git-diff in your browser).

Among the major changes are:

The move to inline documentation and using examples as documentation. One of the biggest complaints we hear from users is the lack of documentation. The README was growing uncontrollably, documentation was out of sync with the version of ChefSpec that was actually published, and there was no way to document when an API was introduced/removed. I’m happy to announce that all of ChefSpec’s documentation is now inline YardDoc and is hosted on RubyDoc.info. Additionally, there are no “hard-core” examples for writing test. The examples directory in the repo is not a one-stop shop with every possible matcher permutation for Chef’s core resources. And better yet - those examples aren’t just for show - they are the all new test suite!
Unified resource matchers. There was often confusion because some matcher included method chaining, and others didn’t. In ChefSpec 3, there’s a general ResourceMatcher that is responsible for all core resources. This ensures that all resources have the method chaining and magic to make things awesome! Centralizing all this logic also allowed for a nice refactor of the custom error messages. The new error messages will make it much easier to debug failing specs.
Removed non-core resource matchers. In short, if it’s not in Chef-core, it’s not a matcher in ChefSpec-core. But wait - I wouldn’t just leave you hanging…
Custom Matchers. A long-requested feature! The new modular pattern allows LWRP authors to package ChefSpec matchers with their LWRPs. Writing matchers is an incredibly pleasurable experience and requires almost no RSpec experience! Start packaging your matchers today :slight_smile:
All new matchers. In addition to removing all non-Chef matchers, we added all the core-Chef matchers.
Easy stubbing. I’m so excited to announce that ChefSpec 3.0 includes NATIVE SEARCH STUBBING in a convenient and easy-to-use DSL format. It has never been easier to stub your requests. As part of this new functionality, we also added methods for stubbing data_bags and data_bag_items. And then to wrap it all up, we now expose a DSL method for stubbing a node object (useful when stubbing search results).
Top-level configuration. In addition to passing attributes to the ChefSpec::Runner’s initialize method, you can now define global configuration options.

That being said, ChefSpec 3.0 is a beta1. It will definitely contain deprecation errors, and it may contain bugs. Please help us test this software by upgrading your projects and reporting any errors or confusion.

If you don’t want to report issue on GitHub, feel free to email me directly with any questions.

This is a great leap forward for the Chef testing ecosystem and I’m very excited to finally get this out in the wild!

Happy Testing!
Seth Vargo
Solutions Engineer, Opscode
@sethvargo


#2

you are awesome :slight_smile: !

On Wed, Oct 9, 2013 at 6:33 PM, Seth Vargo sethvargo@opscode.com wrote:

Ohai Chefs!

I just released chefspec-3.0.0.beta.1, which is a major refactor of the
code base with a focus on documentation, extensibility, and modularity. The
full CHANGELOG can be found at
https://github.com/acrmp/chefspec/blob/master/CHANGELOG.md#300-tbd. (I
highly discourage looking at the git-diff in your browser).

Among the major changes are:

  • The move to inline documentation and using examples as
    documentation.
    One of the biggest complaints we hear from users is
    the lack of documentation. The README was growing uncontrollably,
    documentation was out of sync with the version of ChefSpec that was
    actually published, and there was no way to document when an API was
    introduced/removed. I’m happy to announce that all of ChefSpec’s
    documentation is now inline YardDoc and is hosted on RubyDoc.info.
    Additionally, there are no “hard-core” examples for writing test. The
    examples directory in the repo is not a one-stop shop with every possible
    matcher permutation for Chef’s core resources. And better yet - those
    examples aren’t just for show - they are the all new test suite!
  • Unified resource matchers. There was often confusion because some
    matcher included method chaining, and others didn’t. In ChefSpec 3, there’s
    a general ResourceMatcher that is responsible for all core resources.
    This ensures that all resources have the method chaining and magic to make
    things awesome! Centralizing all this logic also allowed for a nice
    refactor of the custom error messages. The new error messages will make it
    much easier to debug failing specs.
  • Removed non-core resource matchers. In short, if it’s not in
    Chef-core, it’s not a matcher in ChefSpec-core. But wait - I wouldn’t just
    leave you hanging…
  • Custom Matchers. A long-requested feature! The new modular pattern
    allows LWRP authors to package ChefSpec matchers with their LWRPs.
    Writing matchers is an incredibly pleasurable experience and requires
    almost no RSpec experience! Start packaging your matchers today :slight_smile:
  • All new matchers. In addition to removing all non-Chef matchers,
    we added all the core-Chef matchers.
  • Easy stubbing. I’m so excited to announce that ChefSpec 3.0
    includes NATIVE SEARCH STUBBING in a convenient and easy-to-use DSL format.
    It has never been easier to stub your requests. As part of this new
    functionality, we also added methods for stubbing data_bags and
    data_bag_items. And then to wrap it all up, we now expose a DSL method for
    stubbing a node object (useful when stubbing search results).
  • Top-level configuration. In addition to passing attributes to the
    ChefSpec::Runner’s initialize method, you can now define global
    configuration options.

That being said, ChefSpec 3.0 is a beta1. It will definitely contain
deprecation errors, and it may contain bugs. Please help us test this
software by upgrading your projects and reporting any errors or confusion.

If you don’t want to report issue on GitHub, feel free to email me
directly with any questions.

This is a great leap forward for the Chef testing ecosystem and I’m very
excited to finally get this out in the wild!

Happy Testing!
Seth Vargo
Solutions Engineer, Opscode
@sethvargo https://twitter.com/sethvargo


#3

Agreed this change log is very nice… heaps of good stuff!

On Oct 9, 2013, at 6:36 PM, Ranjib Dey dey.ranjib@gmail.com wrote:

you are awesome :slight_smile: !

On Wed, Oct 9, 2013 at 6:33 PM, Seth Vargo sethvargo@opscode.com wrote:
Ohai Chefs!

I just released chefspec-3.0.0.beta.1, which is a major refactor of the code base with a focus on documentation, extensibility, and modularity. The full CHANGELOG can be found at https://github.com/acrmp/chefspec/blob/master/CHANGELOG.md#300-tbd. (I highly discourage looking at the git-diff in your browser).

Among the major changes are:

The move to inline documentation and using examples as documentation. One of the biggest complaints we hear from users is the lack of documentation. The README was growing uncontrollably, documentation was out of sync with the version of ChefSpec that was actually published, and there was no way to document when an API was introduced/removed. I’m happy to announce that all of ChefSpec’s documentation is now inline YardDoc and is hosted on RubyDoc.info. Additionally, there are no “hard-core” examples for writing test. The examples directory in the repo is not a one-stop shop with every possible matcher permutation for Chef’s core resources. And better yet - those examples aren’t just for show - they are the all new test suite!
Unified resource matchers. There was often confusion because some matcher included method chaining, and others didn’t. In ChefSpec 3, there’s a general ResourceMatcher that is responsible for all core resources. This ensures that all resources have the method chaining and magic to make things awesome! Centralizing all this logic also allowed for a nice refactor of the custom error messages. The new error messages will make it much easier to debug failing specs.
Removed non-core resource matchers. In short, if it’s not in Chef-core, it’s not a matcher in ChefSpec-core. But wait - I wouldn’t just leave you hanging…
Custom Matchers. A long-requested feature! The new modular pattern allows LWRP authors to package ChefSpec matchers with their LWRPs. Writing matchers is an incredibly pleasurable experience and requires almost no RSpec experience! Start packaging your matchers today :slight_smile:
All new matchers. In addition to removing all non-Chef matchers, we added all the core-Chef matchers.
Easy stubbing. I’m so excited to announce that ChefSpec 3.0 includes NATIVE SEARCH STUBBING in a convenient and easy-to-use DSL format. It has never been easier to stub your requests. As part of this new functionality, we also added methods for stubbing data_bags and data_bag_items. And then to wrap it all up, we now expose a DSL method for stubbing a node object (useful when stubbing search results).
Top-level configuration. In addition to passing attributes to the ChefSpec::Runner’s initialize method, you can now define global configuration options.

That being said, ChefSpec 3.0 is a beta1. It will definitely contain deprecation errors, and it may contain bugs. Please help us test this software by upgrading your projects and reporting any errors or confusion.

If you don’t want to report issue on GitHub, feel free to email me directly with any questions.

This is a great leap forward for the Chef testing ecosystem and I’m very excited to finally get this out in the wild!

Happy Testing!
Seth Vargo
Solutions Engineer, Opscode
@sethvargo


#4

This sounds awesome and I can’t wait to try it out! Thanks Seth!

  • Julian

On Wed, Oct 9, 2013 at 9:33 PM, Seth Vargo sethvargo@opscode.com wrote:

Ohai Chefs!

I just released chefspec-3.0.0.beta.1, which is a major refactor of the code
base with a focus on documentation, extensibility, and modularity. The full
CHANGELOG can be found at
https://github.com/acrmp/chefspec/blob/master/CHANGELOG.md#300-tbd. (I
highly discourage looking at the git-diff in your browser).

Among the major changes are:

The move to inline documentation and using examples as documentation. One of
the biggest complaints we hear from users is the lack of documentation. The
README was growing uncontrollably, documentation was out of sync with the
version of ChefSpec that was actually published, and there was no way to
document when an API was introduced/removed. I’m happy to announce that all
of ChefSpec’s documentation is now inline YardDoc and is hosted on
RubyDoc.info. Additionally, there are no “hard-core” examples for writing
test. The examples directory in the repo is not a one-stop shop with every
possible matcher permutation for Chef’s core resources. And better yet -
those examples aren’t just for show - they are the all new test suite!
Unified resource matchers. There was often confusion because some matcher
included method chaining, and others didn’t. In ChefSpec 3, there’s a
general ResourceMatcher that is responsible for all core resources. This
ensures that all resources have the method chaining and magic to make things
awesome! Centralizing all this logic also allowed for a nice refactor of the
custom error messages. The new error messages will make it much easier to
debug failing specs.
Removed non-core resource matchers. In short, if it’s not in Chef-core, it’s
not a matcher in ChefSpec-core. But wait - I wouldn’t just leave you
hanging…
Custom Matchers. A long-requested feature! The new modular pattern allows
LWRP authors to package ChefSpec matchers with their LWRPs. Writing matchers
is an incredibly pleasurable experience and requires almost no RSpec
experience! Start packaging your matchers today :slight_smile:
All new matchers. In addition to removing all non-Chef matchers, we added
all the core-Chef matchers.
Easy stubbing. I’m so excited to announce that ChefSpec 3.0 includes NATIVE
SEARCH STUBBING in a convenient and easy-to-use DSL format. It has never
been easier to stub your requests. As part of this new functionality, we
also added methods for stubbing data_bags and data_bag_items. And then to
wrap it all up, we now expose a DSL method for stubbing a node object
(useful when stubbing search results).
Top-level configuration. In addition to passing attributes to the
ChefSpec::Runner’s initialize method, you can now define global
configuration options.

That being said, ChefSpec 3.0 is a beta1. It will definitely contain
deprecation errors, and it may contain bugs. Please help us test this
software by upgrading your projects and reporting any errors or confusion.

If you don’t want to report issue on GitHub, feel free to email me directly
with any questions.

This is a great leap forward for the Chef testing ecosystem and I’m very
excited to finally get this out in the wild!

Happy Testing!
Seth Vargo
Solutions Engineer, Opscode
@sethvargo


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#5

Test All The Things

On Wed, Oct 9, 2013 at 9:33 PM, Seth Vargo sethvargo@opscode.com wrote:

Ohai Chefs!

I just released chefspec-3.0.0.beta.1, which is a major refactor of the
code base with a focus on documentation, extensibility, and modularity. The
full CHANGELOG can be found at
https://github.com/acrmp/chefspec/blob/master/CHANGELOG.md#300-tbd. (I
highly discourage looking at the git-diff in your browser).

Among the major changes are:

  • The move to inline documentation and using examples as
    documentation.
    One of the biggest complaints we hear from users is
    the lack of documentation. The README was growing uncontrollably,
    documentation was out of sync with the version of ChefSpec that was
    actually published, and there was no way to document when an API was
    introduced/removed. I’m happy to announce that all of ChefSpec’s
    documentation is now inline YardDoc and is hosted on RubyDoc.info.
    Additionally, there are no “hard-core” examples for writing test. The
    examples directory in the repo is not a one-stop shop with every possible
    matcher permutation for Chef’s core resources. And better yet - those
    examples aren’t just for show - they are the all new test suite!
  • Unified resource matchers. There was often confusion because some
    matcher included method chaining, and others didn’t. In ChefSpec 3, there’s
    a general ResourceMatcher that is responsible for all core resources.
    This ensures that all resources have the method chaining and magic to make
    things awesome! Centralizing all this logic also allowed for a nice
    refactor of the custom error messages. The new error messages will make it
    much easier to debug failing specs.
  • Removed non-core resource matchers. In short, if it’s not in
    Chef-core, it’s not a matcher in ChefSpec-core. But wait - I wouldn’t just
    leave you hanging…
  • Custom Matchers. A long-requested feature! The new modular pattern
    allows LWRP authors to package ChefSpec matchers with their LWRPs.
    Writing matchers is an incredibly pleasurable experience and requires
    almost no RSpec experience! Start packaging your matchers today :slight_smile:
  • All new matchers. In addition to removing all non-Chef matchers,
    we added all the core-Chef matchers.
  • Easy stubbing. I’m so excited to announce that ChefSpec 3.0
    includes NATIVE SEARCH STUBBING in a convenient and easy-to-use DSL format.
    It has never been easier to stub your requests. As part of this new
    functionality, we also added methods for stubbing data_bags and
    data_bag_items. And then to wrap it all up, we now expose a DSL method for
    stubbing a node object (useful when stubbing search results).
  • Top-level configuration. In addition to passing attributes to the
    ChefSpec::Runner’s initialize method, you can now define global
    configuration options.

That being said, ChefSpec 3.0 is a beta1. It will definitely contain
deprecation errors, and it may contain bugs. Please help us test this
software by upgrading your projects and reporting any errors or confusion.

If you don’t want to report issue on GitHub, feel free to email me
directly with any questions.

This is a great leap forward for the Chef testing ecosystem and I’m very
excited to finally get this out in the wild!

Happy Testing!
Seth Vargo
Solutions Engineer, Opscode
@sethvargo https://twitter.com/sethvargo