defined types facts as default parameter not working

[b4ldr]

Describe the Bug

With a defined that has a default parameter which uses a fact for the default value e.g.

define example::rspec_define (
  $fact_parameter = $facts['os']['distro']['codename']
) {
  file{'/tmp/T291374':
    ensure  => file,
    content => $fact_parameter
  }
}

Testing using rspec-puppet-tests has no affect on the default value. It appears that all tests use the last value in the on_supported_os iterator.

The test i used is:

describe 'example::rspec_define' do
  on_supported_os(test_on).each do |os, facts|
    let(:facts) { facts }
    let(:title) { "test-#{os}" }
    context os do
      context 'test' do
        it { is_expected.to compile }
        it { is_expected.to contain_file('/tmp/T291374').with_content(/#{facts[:os]['distro']['codename']}/) }
      end
    end
  end
end

Expected Behaviour

All test should pass

Actual Behaviour

The file content test above fails when testing debian-10-x86_64 with the following error

  1) example::rspec_define debian-10-x86_64 test is expected to contain File[/tmp/T291374] with content =~ /buster/
     Failure/Error: it { is_expected.to contain_file('/tmp/T291374').with_content(/#{facts[:os]['distro']['codename']}/) }
       expected that the catalogue would contain File[/tmp/T291374] with content set to /buster/ but it is set to "stretch"
     # ./spec/defines/rspec_define_spec.rb:10:in `block (5 levels) in <top (required)>'

Steps to Reproduce

I have created a specific repo to demonstrate this issue
Steps to reproduce the behavior:

1. git clone https://github.com/b4ldr/T291374/
2. cd T291374
3. bundle install
4. bundle exec rake spec

[michaeltlombardi]

@b4ldr taking a look through, it seems like the issue might be with the facts caching in on_supported_os which is actually defined/maintained in voxpupuli/rspec-puppet-facts as you can see here:

https://github.com/voxpupuli/rspec-puppet-facts/blob/master/lib/rspec-puppet-facts.rb#L31-L50

I suspect this issue should be moved to that repository where the maintainers will have better context and availability to solve the problem at the right level.

[ekohl]

@b4ldr I would recommend to use different names so you don't shadow, but that's not the real issue. You don't scope the facts properly. What you must do is to call let inside context:

describe 'example::rspec_define' do
  on_supported_os(test_on).each do |os, os_facts|
    context os do
      let(:facts) { os_facts }
      let(:title) { "test-#{os}" }
      context 'test' do
        it { is_expected.to compile }
        it { is_expected.to contain_file('/tmp/T291374').with_content(/#{facts[:os]['distro']['codename']}/) }
      end
    end
  end
end

This has to do with rspec itself where it first generates classes but it keeps a reference to the facts variable on the describe level. That level is shared between all tests and you overwrite it in every iteration of the loop. After the collection phase it executes the tests which point to the same facts hash. By using the let block there is proper scoping.

You can see this as well with this test:

require 'voxpupuli/test/spec_helper'
test_on = { supported_os: [ 'operatingsystem' => 'Debian', 'operatingsystemrelease' => ['9','10']]}
describe 'example::rspec_define' do
  on_supported_os(test_on).each do |os, os_facts|
    let(:facts) { os_facts }
    let(:title) { "test-#{os}" }
    context os do
      it { is_expected.to compile }
      it { is_expected.to contain_file('/tmp/T291374').with_content(/#{facts[:os]['distro']['codename']}/) }
    end
  end
end

This results in:

example::rspec_define
  debian-10-x86_64
    is expected to compile into a catalogue without dependency cycles
    is expected to contain File[/tmp/T291374] with content =~ /stretch/
  debian-9-x86_64
    is expected to compile into a catalogue without dependency cycles
    is expected to contain File[/tmp/T291374] with content =~ /stretch/

Note how the context is printed correctly but then the facts have an old value.

Edit: I just realized that with voxpupuli/rspec-puppet-facts#132 this wouldn't be a problem: all this complex boiler plate is hidden.

[b4ldr]

@ekohl thanks for the fix and explanation closing as #invalid