chef / chef-vault-testfixtures

provides an RSpec shared context for testing Chef cookbooks that use chef-vault
Apache License 2.0
7 stars 10 forks source link

Double "vault item foo/bar" received unexpected message :empty? with (no args) #18

Open jorhett opened 8 years ago

jorhett commented 8 years ago

Thank you very much for creating and maintaining this cookbook. It looks perfect to allow us to start doing unit testing of chef-vault.

Unfortunately, almost every cookbook here uses vault and they all have code similar to the following in them:

secret_data = chef_vault_item('foo','bar')

template '/tmp/test.conf' do
  action :create
  not_if { secret_data.empty? }
  variables(
    access_id: secret_data['id'],
    access_key: secret_data['key']
  )

Some use nil? or any? methods instead.

This code works fine in production, and with ServerSpec. However when using as documented in the readme I get these errors:

     Failure/Error: chef_run.converge(described_recipe)
       #<Double "vault item foo/bar received unexpected message :empty? with (no args)

I can work around it by hacking the recipe to check for specific keys instead, but rolling that out would require changes in hundreds of places. As a more general purpose fix, how can I add a stub in rspec such that standard Hash methods work on the returned vault, like they do with the ChefVault object instance?

jorhett commented 8 years ago

I recognize that this is probably something I can do by accessing the double and adding more methods, but I'm failing to grok how to access the vault object inside the recipe...

mmcguinn commented 8 years ago

@jorhett, I've also run into this issue (except for a call to each instead of empty?)

The issue can be found here as far as I can tell: https://github.com/chef/chef-vault-testfixtures/blob/master/lib/chef-vault/test_fixtures.rb#L85

The problem is that the only method that got stubbed for the underlying data is [], so that's the only way to access the mocked data. I'm honestly not sure the best to to provide a better set of stubs, especially considering all the various alias' for hash methods, but I'm going to try simply adding a stub for _toh that returns the underlying hash data (which we then should be able to send each or empty? to). That should satisfy most needs, and will avoid doing anything particularly strange during the actual run.