How do you test your puppet code?

While writing puppet code, and before deploying it to production, there are various phases you should test your puppet code at, Syntax validations while writing modules Unit Tests Integration Tests Syntax Validation Puppet comes with parser utility which could be used to validate manifests with .pp extension for syntactical errors.  To use it,  puppet parser validate  <manifest>.pp Unit Tests If you notice, when you generate modules using the following command        puppet module generate  <author>-<module> it creates a scaffolding necessary to write your module.  If you notice, there is a tests directory created along with manifests, with sample init.pp class. The purpose of this tests directory is to write your unit tests, corresponding to each class and/or defined type that you write. And these tests are run when you  apply the code with --noop option.  Here is the official puppet labs documentation  https://docs.puppetlabs.com/guides/tests_smoke.html Integration Tests This is most relevant to your question. Now, as suggested by fellow puppeteers,  vagrant is your friend. But so is docker, or ec2, or openstack, or any other platform where you could launch a vm/cloud instance. You may also want to test it on different versions of operating systems. You would definitely need test cases too.  And  when you want to run tests in automated fashion, you  rather need a framework which would bring all these  components together.  http://kitchen.ci/  does that for you. It has following pluggable components Driver :  vagrant, docker, ec2 Provisioner : Chef, Puppet, Ansible, Shell Platforms: Ubuntu 12.04, Centos 6.6 Test Suites : bats, serverspec, rspec Bringing it all together You are definitely not going run this manually over time, specially when you have a team working on the same module. To bring it all together, you need a CI tool such as Jenkins/Travis integrated with git.  A sample workflow is depicted in the diagram below. Once you have this setup, all you need to do is commit your puppet code and push it to git. From there, it automatically triggers a job with test kitchen, which then , Launches a new environment with a driver. In this case vagrant Uses puppet provisioner to run your code Launches test suite to perform integration tests. Each component here is pluggable. So you could test it using ec2 or openstack instead of vagrant. You could plug out puppet and plug in chef. Same with test suites, you could use Serverspec, or BATS( Bash automated Testing System) or Rspec.

I'm having the same question. The best thing I could think so far (haven't been working with Puppet for long, so forgive me if this is a naive idea) would be to spin up a few vagrant instances so you could easily simulate a master-client communication from your local box. Googling a little bit around Ive found these vagrant add-ons (https://github.com/vStone/vagrant-addons) that should be help you create clients and a master easily with vagrant, but it seems to be work in progress so I still havent managed to execute on my plan.

We have several levels of checking, but sadly nothing alike automated unit testing. We start with a multi-vm vagrant environment as a local development environment.  This environment uses the same images as we use in production it also has a puppet master that is bootstrapped using our hieradata and puppet modules (the same we use in production). This ensures that we have a common development setup that has more or less the same problems as production.  The configuration management data system is mocked at moment. This is the first place the functionality of a module is checked, especially in combination with all the other modules in the environment. On top of that every body uses its own editor, but the more mature setups have syntax highlighting and do online error and lint checking and show the errors inline. you can use syntastic with vim, but gepetto would also work. The local development environment has installed git hooks that force pre-commit syntax-checks (puppet parse, erb) and lint errors (puppet-lint). Which ensure that obviours code and style problems are detected early on. Every commit to the development branch needs to be peer-reviewed using gerrit. Which gives a handle on the quality of the code that goes into the modules.  The get the code into  our environments (test, staging, production, etc).  You need to merge development into master and set an version tag, which goes through peer review.   Each of our environments corresponds to an puppet environment. The contents of these are defined by a per-environment list of module:version tuple's. The modification of this list is again peer-reviewed. And as a rule changes need to percolate from development, test all the way to production. no skipping is allowed. We also have to ability to define temporary custom puppet environments in the datacenter for the situations where the local development environment is adequate for the job. for example due to resource constraints.

Citac is a novel toolkit for systematically testing whether your Puppet scripts make the system converge to the desired target state. It is available on Github: https://github.com/citac/citac Citac systematically executes your Puppet manifest in various configurations, imitating transient system faults, different resource execution orders, and more. The generated test reports inform you about issues with non-idempotent resources, convergence-related issues, etc. Citac uses Docker containers for execution, hence your system remains untouched while testing. State changes are tracked during execution of the Puppet script, and detailed test reports are generated.Please check it out and feel free to provide feedback, pull requests, etc. Happy testing!

You can use puppet apply to test pp files at local, the weakness is you can not connect to the master, so some resources may not work. In our environment we use multi-environment which is supported by puppet. You can find it at http://docs.puppetlabs.com/guides/environment.html

At work, I had this question myself not too long ago. I came up with 3 ways to check things before we rollout: 1) Run 'puppet parser validate' on all our .pp files to validate that it has proper syntax. 2) Run 'erb -x -T '-'' on all of our templates to validate they are ok. 3) Run puppet-lint (https://github.com/rodjek/puppet-lint) on all our .pp files so we have a clean, consistent style. All 3 of these checks are done through a job in jenkins, so I'll know if I screwed up. In general, if I have big changes that I know might break something, I'll rollout to our dev instances first. This is how I verify things will work ok: 1) Logon to all devs boxes and stop puppet on them. 2) Rollout to our dev environment. 3) On all the dev boxes run 'puppet agent -t --noop', which will run the agent, and show you what it would do, but not actually do anything. 4) Rinse and repeat till you are confident you won't break things. (I'd also do this when I rollout to production too. A tool like csshX helps a ton) To get some more bonafide tests, I've been fooling around with puppet-rspec, and writing some unit tests for our codebase. It's slow going, but I think it's worth it: https://github.com/rodjek/rspec-puppet http://bombasticmonkey.com/2011/11/04/test-your-puppet-modules-functions/ This will be easy to hook into our puppet build in Jenkins once I'm done with it also.

I built our entire server infrastructure in vagrant VMs first (puppet, jenkins, caching...), with various $::is_vagrant's in the manifest for dev. The Vagrantfile pulls in from developer-specific configs for things like custom facts and shared folders.  The manifests and modules are synced on the puppetmaster VM so that whatever branch is being worked on locally is instantly available to the PM.  The PM is configured itself via puppet and locally autosigns all certs. Basically any dev can clone the vagrant config, clone the puppet repo and replicate our infrastructure locally to work on any piece of it.

You might find it useful this post: http://www.example42.com/?q=TestingPuppetWithPuppi