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
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!
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 chefspec/CHANGELOG.md at main · chefspec/chefspec · GitHub. (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
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!
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 chefspec/CHANGELOG.md at main · chefspec/chefspec · GitHub. (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
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!
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 chefspec/CHANGELOG.md at main · chefspec/chefspec · GitHub. (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
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!
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 chefspec/CHANGELOG.md at main · chefspec/chefspec · GitHub. (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
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!
!