When it comes to testing puppet modules, there are lot of options, but for someone entering the world of puppet module testing, the pure variety may seem overwhelming. This is a try to provide some overview.
So you’ve written a puppet module and would like to add some tests. Now what?As of today, puppet tests basically can be done in two ways, complementing each other:
- Catalog tests (e.g. testing the compiled puppet catalog)
- Functional/Acceptance tests in a real environment
In most cases you should at least write some catalog tests.
As of writing this (June 2015) the tool of choice is rspec-puppet. There used to be at least one other and you might have heard about it, but it’s deprecated. For an introduction to this tool, you are best served by reading its brief but sufficient docs.
Function acceptance tests
If catalog testing is not enough for you (e.g. you want to test that your website profile is actually installing and serving your site on port 80 and port 443) the next logical step is to write beaker tests for tests in a real system (as real as a virtual machine can be). This is also what you need, if you are writing custom types.
Today’s tool of choice for this job is beaker with beaker-rspec. After you’ve written some rspec tests, this might feel similar. Since the documentation, might not seem very newbie friendly at first glance, the page
lists the relevant pages in the documentation to get started in a sensible order. Basically it’s: Update your modules build depencies (Gemfile), decide for a hypervisor, create (or describe) your test environment, write spec tests and execute them 🙂
Skeleton of a module
If testing puppet modules falls into your lap and you’ve already written your puppet code, it’s to late too start with a module anatomy as generated by
puppet module generate
But: It’s certainly a good bet to know which technologies are todays common best practice.
A very good guide to setting things up and writing tests of both types is the threepart blog post bycamptocamp. It is a basic guide into test-driven development (writing tests before writing actual code) on a practical example.
- Part 0: Setup your environment
- Part 1: Create a simple calss
- Part 2: Create a more complex class and refactor it
- Part 3: create a custom type and provider