gistfile1.md

So, we want to get into the basics of using rspec-puppet to do high level automated testing for our code? Thats simple enough! The instructions below will help set you up with what is a basic "hello world" of usage. We'll start with the simplest tests we can - does it compile?

First, make sure you have the latest PDK installed. As I believe you mentioned, your modules have all been built using PDK or have been converted to be PDK compliant. Ensure that your modules are recent with the current PDK format by using pdk update on the module.

Now, the PDK will establish the scaffolding for the testing that you need. In the case we discussed we were working with a module that utilized additional modules for added functionality. We need to make sure the testing suite is aware of these dependencies for the module under test. To do this we will work with the .fixtures.yml that the PDK has placed in the module. We can either point to modules are they are on the Puppet Forge, or point to internal Git sources. You need to make sure you set this file up to pull in the correct module with the correct name and version from the correct source. More information on setup: https://github.com/puppetlabs/puppetlabs_spec_helper#using-fixtures

Once your fixtures are in place, we create our test(s)! You will have a spec directory created by the PDK, but you may not have a classes directory in there just yet. Please ensure the path spec/classes exists. Next our example testing code. We will create a file named after the thing it is we want to test. For example, if we have a class called "baseline" then we would create a file called baseline_spec.rb under the spec/classes directory. For the contents we can use a bit of boilerplate code:

require 'spec_helper'

describe 'baseline' do
    # Your tests go in here
  it { is_expected.to compile }
end

In the example above, where it says describe 'baseline' do you would swap that out with the name of the class you're really testing. You would create one of these files with one of these sections of boiler plate code for every class within the module you wish to test. Don't explicitly call classes that are from our dependency modules, we're not testing them here as they should be tested as art of their development life cycles. For our purposes they are just dependencies here.

Last but not least "what if my class has mandatory parameters?" Of course, not every invocation is going to be that simple, you may need to set a class parameter to make the code actually work. For that we utilize the "let" part of rspec-puppet. This ability allows you to "let" a parameter be a certain value for the sake of the test. For example, let us say that the baseline class has a "manager_root" parameter that accepts a boolean, we could use the "let" ability to pass a valid value for the parameter.

require 'spec_helper'

describe 'baseline' do
  let(:params) { {'manage_root' => true} }

    # Your tests go in here
  it { is_expected.to compile }
end

In the example above, the "let" is a presenting a hash or value. That is an important distinction in the event you need to pass more parameters. Just extend the hash with more parameter names and values as needed.

Finally, we're done, the moment of truth, will it compile? This part is easy. Assuming everything else is fine we can run this test! From the root of the module, you should be able to simply say pdk test unit and away we go! You'll see it prepare the test, and run the test. Hopefully the results are that it passed. But next time you're updating a dependency, such as stdlib for example, you can modify the .fixtures.yml file to test it on your code in an automated fashion. Also, when hooked into a CI/CD workflow (such as Continuous Delivery for Puppet Enterprise), any change made to the code can kick off a test like that.