chefspec 5.3.0 → 5.4.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: cd963cf180a20e6c7271d54e58c941c719052754
-  data.tar.gz: cc514dca888b1a8c99fcd4e4c917dc56df2ff8e5
+  metadata.gz: 211571e6c3653dfe0f5a14afc11aa7dc345ef5e2
+  data.tar.gz: e26799c5d30d08c00e23589efcff3ce68c64ca2f
 SHA512:
-  metadata.gz: e3cc38869f14061cbe3b2ebaf3f6c46042429925b7495ef55b5471074f23a6afb435dd7aebfad101a4ffa943ef793fb28b176159a3bd5dd390365a3e7cd50e2c
-  data.tar.gz: 1f5f5cf99b9926d07232b850d195d2817c58200d773ca419e16dd7fe64b9f3f81c93ad5fa931835e2430eb05787a8e4df94f0cc03ecc9fc39b9e4bbfeb58ea03
+  metadata.gz: 5837c6e05f8f156084ca693bcdbe6942817ccb6be32c6b93aa9f56ab1aca5e28db6a1dcc6abae66b89399362f38728d96e3fe13a5a111370ae8a1ebe5f249992
+  data.tar.gz: e7ba13ba29067d4f13c550bea471d7ff017416470f83247d6c131ca3868d1992315041eae4371121132f6d88d11b4fc086309d8280776bb7acc76b2b73d392d5

data/.travis.yml

@@ -27,12 +27,6 @@ env:
   - CHEF_VERSION=12.8.1
   - CHEF_VERSION=12.7.2
   - CHEF_VERSION=12.6.0
-  - CHEF_VERSION=12.5.1
-  - CHEF_VERSION=12.4.3
-  - CHEF_VERSION=12.3.0
-  - CHEF_VERSION=12.2.1
-  - CHEF_VERSION=12.1.2
-  - CHEF_VERSION=12.0.3
 
 matrix:
   fast_finish: true

data/CHANGELOG.md

@@ -1,6 +1,17 @@
 # CHANGELOG for ChefSpec
 
-## 5.3.0 (October 20, 2016)
+## 5.4.0 (February 9, 2017)
+
+IMPROVEMENTS
+
+- Support for in-memory or on-disk ChefZero Servers. See README for usage details.
+
+UPDATES
+
+- While Chef 12.0 - 12.5 are still supported, they are no longer being tested.
+
+
+## 5.3.0 (October 29, 2016)
 
 IMPROVEMENTS
 

data/README.md

@@ -1,10 +1,6 @@
-ChefSpec
-========
-[![Gem Version](http://img.shields.io/gem/v/chefspec.svg)][gem]
-[![Build Status](http://img.shields.io/travis/sethvargo/chefspec.svg)][travis]
+# ChefSpec
 
-[gem]: https://rubygems.org/gems/chefspec
-[travis]: http://travis-ci.org/sethvargo/chefspec
+[![Gem Version](https://badge.fury.io/rb/chefspec.svg)](https://badge.fury.io/rb/chefspec) [![Build Status](https://travis-ci.org/sethvargo/chefspec.svg?branch=master)](https://travis-ci.org/sethvargo/chefspec)
 
 ChefSpec is a unit testing framework for testing Chef cookbooks. ChefSpec makes it easy to write examples and get fast feedback on cookbook changes without the need for virtual machines or cloud servers.
 
@@ -13,33 +9,29 @@ ChefSpec runs your cookbook(s) locally with Chef Solo without actually convergin
 - It's really fast!
 - Your tests can vary node attributes, operating systems, and search results to assert behavior under varying conditions.
 
+## What people are saying
 
-What people are saying
-----------------------
 > I just wanted to drop you a line to say "HELL YES!" to ChefSpec. - [Joe Goggins](https://twitter.com/jgoggins)
 
 > OK ChefSpec is my new best friend. Delightful few hours working with it. - [Michael Ivey](https://twitter.com/ivey)
 
 **Chat with us - [#chefspec](irc://irc.freenode.net/chefspec) on Freenode**
 
+## Important Notes
 
-Important Notes
----------------
-- **ChefSpec requires Ruby 2.1 or later and Chef 12.0.2 or later!**
+- **ChefSpec requires Ruby 2.1 or later and Chef 12.6 or later!**
 - **This documentation corresponds to the master branch, which may be unreleased. Please check the README of the latest git tag or the gem's source for your version's documentation!**
 - **Each resource matcher is self-documented using [Yard](http://rubydoc.info/github/sethvargo/chefspec) and has a corresponding aruba test from the [examples directory](https://github.com/sethvargo/chefspec/tree/master/examples).**
 - **ChefSpec aims to maintain compatibility with the two most recent minor versions of Chef.** If you are running an older version of Chef it may work, or you will need to run an older version of ChefSpec.
 
+## Notes on Compatibility with Chef Versions
 
-Notes on Compatibility with Chef Versions
------------------------------------------
 As a general rule, if it is tested in the Travis CI matrix, it is a supported version. The section below details any specific versions that are _not_ supported and why:
 
 Additionally, if you look at a cucumber feature and see a tag like `@not_chef_x_y_z`, that means that particular functionality is not supported on those versions of Chef.
 
+## Writing a Cookbook Example
 
-Writing a Cookbook Example
---------------------------
 If you want `knife` to automatically generate spec stubs for you, install [knife-spec](https://github.com/sethvargo/knife-spec).
 
 Given an extremely basic Chef recipe that just installs an operating system package:
@@ -65,14 +57,13 @@ end
 Let's step through this file to see what is happening:
 
 1. At the top of the spec file we require the chefspec gem. This is required so that our custom matchers are loaded. In larger projects, it is common practice to create a file named "spec_helper.rb" and include ChefSpec and perform other setup tasks in that file.
-1. The `describe` keyword is part of RSpec and indicates that everything nested beneath is describing the `example::default` recipe. The convention is to have a separate spec for each recipe in your cookbook.
-1. The `let` block on creates the `ChefSpec:Runner` and then does a fake Chef run with the run_list of `example::default`. Any subsequent examples can then refer to `chef_run` in order to make assertions about the resources that were created during the mock converge.
-1. The `described_recipe` macro is a ChefSpec helper method that infers the recipe from the `describe` block. Alternatively you could specify the recipe directly.
-1. The `it` block is an example specifying that the `foo` package is installed. Normally you will have multiple `it` blocks per recipe, each making a single assertion.
+2. The `describe` keyword is part of RSpec and indicates that everything nested beneath is describing the `example::default` recipe. The convention is to have a separate spec for each recipe in your cookbook.
+3. The `let` block on creates the `ChefSpec:Runner` and then does a fake Chef run with the run_list of `example::default`. Any subsequent examples can then refer to `chef_run` in order to make assertions about the resources that were created during the mock converge.
+4. The `described_recipe` macro is a ChefSpec helper method that infers the recipe from the `describe` block. Alternatively you could specify the recipe directly.
+5. The `it` block is an example specifying that the `foo` package is installed. Normally you will have multiple `it` blocks per recipe, each making a single assertion.
 
+## Configuration
 
-Configuration
--------------
 ChefSpec exposes a configuration layer at the global level and at the `Runner` level. The following settings are available:
 
 ```ruby
@@ -101,6 +92,9 @@ RSpec.configure do |config|
 
   # Specify the operating version to mock Ohai data from (default: nil)
   config.version = '14.04'
+
+  # When using ChefSpec::ServerRunner, specify the data storage method (options: in_memory, on_disk; default: in_memory)
+  config.server_runner_data_store = :on_disk
 end
 ```
 
@@ -129,6 +123,7 @@ ChefSpec::SoloRunner.new(log_level: :debug).converge(described_recipe)
 **NOTE** You do not _need_ to specify a platform and version to use ChefSpec. However, some cookbooks may rely on [Ohai](http://github.com/chef/ohai) data that ChefSpec cannot not automatically generate. Specifying the `platform` and `version` keys instructs ChefSpec to load stubbed Ohai attributes from another platform using [fauxhai](https://github.com/customink/fauxhai).
 
 ### Berkshelf
+
 If you are using Berkshelf, simply require `chefspec/berkshelf` in your `spec_helper` after requiring `chefspec`:
 
 ```ruby
@@ -169,8 +164,7 @@ Requiring this file will:
 - Download all the dependencies listed in your `Cheffile` into the temporary directory
 - Set ChefSpec's `cookbook_path` to the temporary directory
 
-**NOTE** In order to test the cookbook in the current working directory, you
-have to write your `Cheffile` like this:
+**NOTE** In order to test the cookbook in the current working directory, you have to write your `Cheffile` like this:
 
 ```ruby
 # Cheffile
@@ -180,6 +174,7 @@ cookbook 'name_of_your_cookbook', path: '.'
 ```
 
 ### Policyfile
+
 If you are using Chef Policies with ChefDK, simply require `chefspec/policyfile` in your `spec_helper`, and ensure you are using the `ChefSpec::ServerRunner` - Chef Solo does not support the exported repository format because the cookbook names use the unique version identifier.
 
 ```ruby
@@ -203,8 +198,8 @@ default_source :community
 cookbook 'my-cookbook', path: '.'
 ```
 
-Running Specs
--------------
+## Running Specs
+
 ChefSpec is actually an RSpec extension, so you can run your tests using the RSpec CLI:
 
 ```bash
@@ -219,9 +214,8 @@ $ rspec spec/unit/recipes/default_spec.rb --color
 
 For more information on the RSpec CLI, please see the [documentation](https://relishapp.com/rspec/rspec-core/docs/command-line).
 
+## Making Assertions
 
-Making Assertions
------------------
 ChefSpec asserts that resource actions have been performed. In general, ChefSpec follows the following pattern:
 
 ```ruby
@@ -280,7 +274,8 @@ ChefSpec includes matchers for all of Chef's core resources using the above sche
 
 Additionally, ChefSpec includes the following helpful matchers. They are also [documented in Yard](http://rubydoc.info/github/sethvargo/chefspec), but they are included here because they do not follow the "general pattern".
 
-##### include_recipe
+### include_recipe
+
 Assert that the Chef run included a recipe from another cookbook
 
 ```ruby
@@ -305,7 +300,8 @@ describe 'example::default' do
 end
 ```
 
-##### notify
+### notify
+
 Assert that a resource notifies another in the Chef run
 
 ```ruby
@@ -313,7 +309,8 @@ resource = chef_run.template('/etc/foo')
 expect(resource).to notify('service[apache2]').to(:restart).immediately
 ```
 
-##### subscribes
+### subscribes
+
 Assert that a resource subscribes to another in the Chef run
 
 ```ruby
@@ -321,7 +318,8 @@ resource = chef_run.service('apache2')
 expect(resource).to subscribe_to('template[/etc/foo]').on(:create).delayed
 ```
 
-##### render_file
+### render_file
+
 Assert that the Chef run renders a file (with optional content); this will match `cookbook_file`, `file`, and `template` resources and can also check the resulting content
 
 ```ruby
@@ -360,7 +358,8 @@ expect(chef_run).to install_package('apache2').at_converge_time
 
 Since "converge time" is the default behavior for all recipes, this test might be redundant and the predicate could be dropped depending on your situation.
 
-##### do_nothing
+### do_nothing
+
 Assert that a resource performs no action
 
 ```ruby
@@ -370,9 +369,8 @@ expect(resource).to do_nothing
 
 **For more complex examples, please see the [examples directory](https://github.com/sethvargo/chefspec/tree/master/examples) or the [Yard documentation](http://rubydoc.info/github/sethvargo/chefspec).**
 
+## Setting node Attributes
 
-Setting node Attributes
------------------------
 Node attribute can be set when creating the `Runner`. The initializer yields a block that gives full access to the node object:
 
 ```ruby
@@ -386,6 +384,7 @@ end
 ```
 
 ### Automatic attributes
+
 ChefSpec provides mocked automatic Ohai data using [fauxhai](https://github.com/customink/fauxhai). To mock out `automatic` attributes, you must use the `automatic` key:
 
 ```ruby
@@ -415,8 +414,8 @@ describe 'example::default' do
 end
 ```
 
-Using a Chef Server
--------------------
+## Using a Chef Server
+
 All the examples thus far have used the `ChefSpec::SoloRunner`, which runs ChefSpec in Chef Solo mode. ChefSpec also includes the ability to create in-memory Chef Servers. This server can be populated with fake data and used to test search, data bags, and other "server-only" features.
 
 To use the ChefSpec server, simply replace `ChefSpec::SoloRunner` with `ChefSpec::ServerRunner`:
@@ -431,6 +430,7 @@ end
 This will automatically create a Chef Server, synchronize all the cookbooks in your `cookbook_path`, and wire all the internals of Chef together. Recipe calls to `search`, `data_bag` and `data_bag_item` will now query this ChefSpec server.
 
 ### DSL
+
 The ChefSpec server includes a collection of helpful DSL methods for populating data into the Chef Server.
 
 Create a client:
@@ -511,10 +511,14 @@ end
 
 **NOTE** The ChefSpec server is empty at the start of each example to avoid interdependent tests.
 
+### Data Store
+
+The `ServerRunner` has two options for how it will store data: `in_memory` or `on_disk`. The default value is `in_memory`. These two options have different performance implications based on your specific setup. If you are running into performance problems (slow tests, frequent hanging, etc) with one setting, try using the other.
+
+## Stubbing
 
-Stubbing
---------
 ### Command
+
 Given a recipe with shell guard:
 
 ```ruby
@@ -588,6 +592,7 @@ end
 ```
 
 Stub the output of the library helper. [Additional information](http://jtimberman.housepub.org/blog/2015/05/30/quick-tip-stubbing-library-helpers-in-chefspec/)
+
 ```ruby
 before do
   allow_any_instance_of(Chef::Node).to receive(:has_bacon?).and_return(true)
@@ -595,6 +600,7 @@ end
 ```
 
 ### Data Bag & Data Bag Item
+
 **NOTE** This is not required if you are using a ChefSpec server.
 
 Given a recipe that executes a `data_bag` method:
@@ -653,6 +659,7 @@ end
 ```
 
 ### Search
+
 **NOTE** This is not required if you are using a ChefSpec server.
 
 Because ChefSpec is a unit-testing framework, it is recommended that all third-party API calls be mocked or stubbed. ChefSpec exposes a helpful RSpec macro for stubbing search results in your tests. If you converge a Chef recipe that implements a `search` call, ChefSpec will throw an error like:
@@ -689,9 +696,8 @@ describe 'example::default' do
 end
 ```
 
+## Reporting
 
-Reporting
----------
 ChefSpec can generate a report of resources read over resources tested.
 
 To generate the coverage report, add the following to your `spec_helper.rb` before you require any "Chef" code:
@@ -754,7 +760,7 @@ For more complex scenarios, you can create a custom `Filter` object that inherit
 
 ```ruby
 class CustomFilter < ChefSpec::Coverage::Filter
-  def initialize(arg1, arg2, &block)
+  def initialize(arg1, arg2, █)
     # Create a custom initialization method, do some magic, etc.
   end
 
@@ -786,7 +792,8 @@ ChefSpec::Coverage.start! do
   set_template 'json.erb'
 end
 ```
-Provided templates are human.erb*(default)*, table.erb and json.erb, to supply a custom template, specify a relative(to run directory) or absolute path.
+
+Provided templates are human.erb_(default)_, table.erb and json.erb, to supply a custom template, specify a relative(to run directory) or absolute path.
 
 ```ruby
 ChefSpec::Coverage.start! do
@@ -794,9 +801,10 @@ ChefSpec::Coverage.start! do
 end
 ```
 
-Mocking Out Environments
-------------------------
+## Mocking Out Environments
+
 ### ServerRunner
+
 ```ruby
 ChefSpec::ServerRunner.new do |node, server|
   # Create the environment
@@ -808,6 +816,7 @@ end
 ```
 
 ### SoloRunner
+
 If you want to mock out `node.chef_environment`, you'll need to use RSpec mocks/stubs twice:
 
 ```ruby
@@ -828,9 +837,8 @@ end
 
 **There is probably a better/easier way to do this. If you have a better solution, please open an issue or Pull Request so we can make this less painful :)**
 
+## Testing LWRPs
 
-Testing LWRPs
--------------
 **WARNING** Cookbooks with dashes (hyphens) are difficult to test with ChefSpec because of how Chef classifies objects. We recommend naming cookbooks with underscores (`_`) instead of dashes (`-`).
 
 ChefSpec overrides all providers to take no action (otherwise it would actually converge your system). This means that the steps inside your LWRP are not actually executed. If an LWRP performs actions, those actions are never executed or added to the resource collection.
@@ -853,9 +861,8 @@ end
 
 **NOTE:** If your cookbook exposes LWRPs, it is highly recommended you also create a `libraries/matchers.rb` file as outlined below in the "Packaging Custom Matchers" section. **You should never `step_into` an LWRP unless you are testing it. Never `step_into` an LWRP from another cookbook!**
 
+## Packaging Custom Matchers
 
-Packaging Custom Matchers
--------------------------
 ChefSpec exposes the ability for cookbook authors to package custom matchers inside a cookbook so that other developers may take advantage of them in testing. This is done by creating a special library file in the cookbook named `matchers.rb`:
 
 ```ruby
@@ -876,13 +883,15 @@ end
   ```
 
 3. `ChefSpec::Matchers::ResourceMatcher` accepts three parameters:
-    1. The name of the resource to find in the resource collection (i.e. the name of the LWRP).
-    2. The action that resource should receive.
-    3. The value of the name attribute of the resource to find. (This is typically proxied as the value from the matcher definition.)
+
+  1. The name of the resource to find in the resource collection (i.e. the name of the LWRP).
+  2. The action that resource should receive.
+  3. The value of the name attribute of the resource to find. (This is typically proxied as the value from the matcher definition.)
 
 ChefSpec's built-in `ResourceMatcher` _should_ satisfy most common use cases for packaging a custom matcher with your LWRPs. However, if your cookbook is extending Chef core or is outside of the scope of a traditional "resource", you may need to create a custom matcher. For more information on custom matchers in RSpec, please [watch the Railscast on Custom Matchers](http://railscasts.com/episodes/157-rspec-matchers-macros) or look at some of the other custom matchers in ChefSpec's source code.
 
-#### Example
+### Example
+
 Suppose I have a cookbook named "motd" with a resource/provider "message".
 
 ```ruby
@@ -950,9 +959,8 @@ end
 
 Notice that we have changed the name of the method to match the "foobar" action, but the resource matcher definition remains unchanged. When the Chef run executes, the resource will be inserted into the collection as `motd_message`, even though it was given a custom provides.
 
+## Writing Custom Matchers
 
-Writing Custom Matchers
------------------------
 If you are testing a cookbook that does not package its LWRP matchers, you can create your own following the same pattern as the "Packaging Custom Matchers" section. Simply, create a file at `spec/support/matchers.rb` and add your resource matchers:
 
 ```ruby
@@ -970,6 +978,8 @@ require_relative 'support/matchers'
 
 Please use this as a _temporary_ solution. Consider sending a Pull Request to the LWRP author(s) packaging the custom resource matchers (see previous section).
 
+## Matchers for looking up custom resources
+
 ChefSpec also provides a helper method to define a method on the Chef runner for locating a resource in the collection. This is helpful while asserting against custom resource notifications.
 
 ```ruby
@@ -988,9 +998,10 @@ it 'notifies the thing' do
 end
 ```
 
+You can use this functionality to bundle lookup matchers with cookbooks, or to provide your own when the upstream cookbook doesn't include it.
+
+## Expecting Exceptions
 
-Expecting Exceptions
---------------------
 In Chef 11, custom formatters were introduced and ChefSpec uses a custom formatter to suppress Chef Client output. In the event of a convergence failure, ChefSpec will output the error message from the run to help you debug:
 
 ```text
@@ -1041,8 +1052,8 @@ it 'raises an error' do
 end
 ```
 
-Testing Multiple Recipes
--------------
+## Testing Multiple Recipes
+
 Even though ChefSpec is cookbook-centric, you can still converge multiple recipes in a single `ChefSpec::SoloRunner` instance. Given a cookbook "sandwich" with recipes "bacon", "lettuce" and "tomato":
 
 ```ruby
@@ -1066,8 +1077,8 @@ expect(chef_run).to install_package('lettuce')
 expect(chef_run).to install_package('tomato')
 ```
 
-Testing Roles
--------------
+## Testing Roles
+
 Roles can also be used in a single `ChefSpec::SoloRunner` instance. Given a cookbook "bacon" with a default recipe:
 
 ```ruby
@@ -1126,9 +1137,8 @@ end
 ChefSpec::SoloRunner.new(role_path: '/var/my/roles') # local setting
 ```
 
+## Faster Specs
 
-Faster Specs
-------------
 ChefSpec aims to provide the easiest and simplest path for new users to write RSpec examples for Chef cookbooks. In doing so, it makes some sacrifices in terms of speed and agility of execution. In other words, ChefSpec favors "speed to develop" over "speed to execute". Many of these decisions are directly related to the way Chef dynamically loads resources at runtime.
 
 If you understand how RSpec works and would like to see some significant speed improvements in your specs, you can use the `ChefSpec::Cacher` module inspired by [Juri Timošin](https://github.com/DracoAter). Simply convert all your `let` blocks to `cached`:
@@ -1143,9 +1153,8 @@ cached(:chef_run) { ChefSpec::SoloRunner.new }
 
 Everything else should work the same. Be advised, as the method name suggests, this will cache the results of your Chef Client Run for the **entire RSpec example**. This makes stubbing more of a challenge, since the node is already converged. For more information, please see [Juri Timošin's blog post on faster specs](http://dracoater.blogspot.com/2013/12/testing-chef-cookbooks-part-25-speeding.html) as well as the discussion in [#275](https://github.com/sethvargo/chefspec/issues/275).
 
+## Media & Third-party Tutorials
 
-Media & Third-party Tutorials
------------------------------
 - [CustomInk's Testing Chef Cookbooks](http://technology.customink.com/blog/2012/08/03/testing-chef-cookbooks/)
 - [Jake Vanderdray's Practical ChefSpec](http://files.meetup.com/1780846/ChefSpec.pdf)
 - [Jim Hopp's excellent Test Driven Development for Chef Practitioners](http://www.youtube.com/watch?v=o2e0aZUAVGw)
@@ -1155,9 +1164,8 @@ Media & Third-party Tutorials
 - [Seth Vargo's TDDing tmux talk](http://www.confreaks.com/videos/2364-mwrc2013-tdding-tmux)
 - [Stephen Nelson Smith's Test-Driven Infrastructure with Chef](http://shop.oreilly.com/product/0636920030973.do)
 
+## Development
 
-Development
------------
 1. Fork the repository from GitHub.
 2. Clone your fork to your local machine:
 
@@ -1172,16 +1180,19 @@ Development
   ```
 
 4. **Write tests**
+
 5. Make your changes/patches/fixes, committing appropriately
+
 6. Run the tests: `bundle exec rake`
+
 7. Push your changes to GitHub
+
 8. Open a Pull Request
 
-ChefSpec is on [Travis CI](http://travis-ci.org/sethvargo/chefspec) which tests against multiple Chef and Ruby versions.
+ChefSpec is on [Travis CI][travis] which tests against multiple Chef and Ruby versions.
 
 If you are contributing, please see the [Contributing Guidelines](https://github.com/sethvargo/chefspec/blob/master/CONTRIBUTING.md) for more information.
 
+## License
 
-License
--------
 MIT - see the accompanying [LICENSE](https://github.com/sethvargo/chefspec/blob/master/LICENSE) file for details.

data/features/apt_repository.feature

@@ -1,9 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-@not_chef_12_4_3
-@not_chef_12_5_1
 @not_chef_12_6_0
 @not_chef_12_7_2
 @not_chef_12_8_1

data/features/apt_update.feature

@@ -1,9 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-@not_chef_12_4_3
-@not_chef_12_5_1
 @not_chef_12_6_0
 
 Feature: The apt_update matcher

data/features/chocolatey_package.feature

@@ -1,9 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-@not_chef_12_4_3
-@not_chef_12_5_1
 @not_chef_12_6_0
 
 Feature: The chocolatey_package matcher

data/features/dsc_resource.feature

@@ -1,6 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-
 Feature: The dsc_resource matcher
   Background:
     * I am using the "dsc_resource" cookbook

data/features/launchd.feature

@@ -1,9 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-@not_chef_12_4_3
-@not_chef_12_5_1
 @not_chef_12_6_0
 @not_chef_12_7_2
 

data/features/notifications.feature

@@ -1,10 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-@not_chef_12_4_3
-@not_chef_12_5_1
-
 Feature: The notifications matcher
   Background:
     * I am using the "notifications" cookbook

data/features/openbsd_package.feature

@@ -1,5 +1,3 @@
-@not_chef_12_0_3
-
 Feature: The openbsd_package matcher
   Background:
     * I am using the "openbsd_package" cookbook

data/features/osx_profile.feature

@@ -1,9 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-@not_chef_12_4_3
-@not_chef_12_5_1
 @not_chef_12_6_0
 
 Feature: The osx_profile matcher

data/features/paludis_package.feature

@@ -1,5 +1,3 @@
-@not_chef_12_0_3
-
 Feature: The paludis_package matcher
   Background:
     * I am using the "paludis_package" cookbook

data/features/script.feature

@@ -1,10 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-@not_chef_12_4_3
-@not_chef_12_5_1
-
 Feature: The script matcher
   Background:
     * I am using the "script" cookbook

data/features/server_on_disk.feature

@@ -0,0 +1,16 @@
+Feature: The ChefSpec server with on-disk storage
+  Background:
+    * I am using the "server" cookbook
+
+  Scenario Outline: Running specs
+    * I successfully run `rspec spec/<Component>_spec.rb --require ../../../features/support/on_disk.rb`
+    * the output should contain "0 failures"
+  Examples:
+    | Component          |
+    | client             |
+    | data_bag           |
+    | environment        |
+    | node               |
+    | render_with_cached |
+    | role               |
+    | search             |

data/features/subscribes.feature

@@ -1,10 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-@not_chef_12_4_3
-@not_chef_12_5_1
-
 Feature: The subscribes matcher
   Background:
     * I am using the "subscribes" cookbook

data/features/support/on_disk.rb

@@ -0,0 +1,7 @@
+# We need to add this setting because for the first test, we haven't had a chance
+# to load the chefspec rspec.rb file, so the first test will fail if we simply
+# try to set it like we would otherwise.
+
+RSpec.configure do |config|
+  config.add_setting :server_runner_data_store, default: :on_disk
+end

data/features/systemd_unit.feature

@@ -1,9 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-@not_chef_12_4_3
-@not_chef_12_5_1
 @not_chef_12_6_0
 @not_chef_12_7_2
 @not_chef_12_8_1

data/features/windows_package.feature

@@ -1,8 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-
 Feature: The windows_package matcher
   Background:
     * I am using the "windows_package" cookbook

data/features/yum_repository.feature

@@ -1,9 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-@not_chef_12_4_3
-@not_chef_12_5_1
 @not_chef_12_6_0
 @not_chef_12_7_2
 @not_chef_12_8_1

data/features/zypper_package.feature

@@ -1,8 +1,3 @@
-@not_chef_12_0_3
-@not_chef_12_1_2
-@not_chef_12_2_1
-@not_chef_12_3_0
-
 Feature: The zypper_package matcher
   Background:
     * I am using the "zypper_package" cookbook

data/gemfiles/chefspec.gemfile

@@ -1,11 +1,5 @@
 source 'https://rubygems.org'
 
-# travis runs on older chef releases failed while including
-# rack 2.X on Ruby 2.1. When we remove Ruby 2.1 support this can go
-if ENV['CHEF_VERSION'].to_f < 12.6
-  gem 'rack', '~> 1.0'
-end
-
 if ENV['CHEF_VERSION'] == 'master'
   gem 'chef', github: 'chef/chef'
 else

data/lib/chefspec/rspec.rb

@@ -19,4 +19,5 @@ RSpec.configure do |config|
   config.add_setting :path
   config.add_setting :platform
   config.add_setting :version
+  config.add_setting :server_runner_data_store, default: :in_memory
 end

data/lib/chefspec/server_methods.rb

@@ -16,6 +16,9 @@ module ChefSpec
 
         # Set a random port so ChefSpec may be run in multiple contexts
         port: port,
+
+        # Set the data store
+        data_store: data_store(RSpec.configuration.server_runner_data_store),
       )
     end
 
@@ -172,5 +175,27 @@ module ChefSpec
         @server.data_store.get(args)
       end
     end
+
+    #
+    # Generate the DataStore object to be passed in to the ChefZero::Server object
+    #
+    def data_store(option)
+      require "chef_zero/data_store/default_facade"
+
+      store = case option
+              when :in_memory
+                require "chef_zero/data_store/memory_store_v2"
+                ChefZero::DataStore::MemoryStoreV2.new
+              when :on_disk
+                require "tmpdir"
+                require "chef_zero/data_store/raw_file_store"
+                tmpdir = Dir.mktmpdir
+                ChefZero::DataStore::RawFileStore.new(Dir.mktmpdir)
+              else
+                raise ArgumentError, ":#{option} is not a valid server_runner_data_store option. Please use either :in_memory or :on_disk."
+              end
+
+      ChefZero::DataStore::DefaultFacade.new(store, "chef", true)
+    end
   end
 end

data/lib/chefspec/version.rb

@@ -1,3 +1,3 @@
 module ChefSpec
-  VERSION = '5.3.0'
+  VERSION = '5.4.0'
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: chefspec
 version: !ruby/object:Gem::Version
-  version: 5.3.0
+  version: 5.4.0
 platform: ruby
 authors:
 - Andrew Crump
@@ -9,7 +9,7 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2016-10-30 00:00:00.000000000 Z
+date: 2017-02-10 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: chef
@@ -736,6 +736,7 @@ files:
 - features/ruby_block.feature
 - features/script.feature
 - features/server.feature
+- features/server_on_disk.feature
 - features/service.feature
 - features/smartos_package.feature
 - features/solaris_package.feature
@@ -751,6 +752,7 @@ files:
 - features/subversion.feature
 - features/support/env.rb
 - features/support/executor.rb
+- features/support/on_disk.rb
 - features/systemd_unit.feature
 - features/template.feature
 - features/use_inline_resources.feature
@@ -940,7 +942,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.6.7
+rubygems_version: 2.6.10
 signing_key: 
 specification_version: 4
 summary: Write RSpec examples and generate coverage reports for Chef recipes!
@@ -1009,6 +1011,7 @@ test_files:
 - features/ruby_block.feature
 - features/script.feature
 - features/server.feature
+- features/server_on_disk.feature
 - features/service.feature
 - features/smartos_package.feature
 - features/solaris_package.feature
@@ -1024,6 +1027,7 @@ test_files:
 - features/subversion.feature
 - features/support/env.rb
 - features/support/executor.rb
+- features/support/on_disk.rb
 - features/systemd_unit.feature
 - features/template.feature
 - features/use_inline_resources.feature