Always test your puppet modules. Even if it’s just a little smoke test like this:

1

class { my_module: }

Now to make this one better, create a job on your continuous integration server and let it run the following script inside the modules directory of your puppet project:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

#!/bin/bash

#DEBUG="--verbose --debug"
hash puppet 2>/dev/null || { echo >&2 "Please install puppet"; exit 2; }
[ -z "$(facter | grep fqdn)" ] && { echo >&2 "Your machine has no FQDN (according to facter), some tests may fail or print warnings"; sleep 5; }

for dir in $(find . -type d -name tests); do
 for file in $(find ${dir} -name '*.pp'); do
  echo ">>> TESTING ${file}"
  puppet apply ${DEBUG} --modulepath modules --noop "${file}" || { echo ">>> ERROR" ; HAS_FAILURES="true" ; }
  echo "------------------------------------------------------------------------------"
 done
done

if [ "${HAS_FAILURES}" = "true" ]; then
 exit 1
fi

It looks for all ‘*.pp’ files inside all ’tests’ directories and does a simple ‘puppet apply’ call. It may not be perfect but it’s small, simple, it works and it’ll save you some gray hairs.

The next logical step would be to have a playground of virtual servers newly initialized from scratch/snapshot where you can actually run the modules and verify they behave as expected. All this with a config that’s as close to your productive environment as possible so you catch and fix as many problems as possible in a throwaway environment instead of production. Unfortunately there’s no way I’ll be doing something as extensive as this in the forseeable future.

Another interesting thing would be to write JUnit/TestNG compatible reporting xml files so your build server will be able to display results of individual tests and distinguis successful from failed tests.