Started looking at beaker, the acceptance test framework from puppetlabs yesterday. Hunter Haugen’s video (below) gives a good overview of the capabilities of the tool.

Getting started with beaker is pretty simple. It took me only a few minutes to clone puppetlabs/puppetlabs-apache and run the contained tests. Actually, running the tests took a bit longer. This is also the biggest problem with beaker: running tests takes even for small modules with a single node at least two to three minutes, even on my not-so-underpowered workstation.

A solution is vmpooler, a “hypervisor” for beaker to clone running VMs from templates. This reduces the setup time for tests significantly, but requires VSphere as backend. :-/

Some notes about writing tests with beaker:

  • Contrary to rspec-puppet, beaker (with rspec-system) can be used to validate a module against a set of high-level specifications. Examples:
    • “Applying the class two times in a row causes no errors in the first run and no changes in the second run.”
    • “After applying the class, http://localhost:80/phpinfo.php returns the PHP version.”
    • “After applying the class, a customer can login and browse the catalog.”
  • Specifications that are testable with rspec-puppet SHOULD be tested there. It doesn’t make sense to spin up a VM to check that specifying an invalid set of arguments causes a compilation error in puppet.

  • All tests seem to run on the same machine, in definition order. This makes sense, as the setup is the only thing taking much time. On the other hand, this couples tests.

  • Required files, copy from existing modules:
    • Gemfile
    • spec/acceptance/nodesets/default.yml
    • spec/spec_helper_acceptance.rb
    • spec/acceptance/class_spec.rb

Diving Deeper in to Beaker - Acceptance testing for Puppet

Test commits