There’s a growing movement for testing chef cookbooks, which is great to see. I haven’t gotten to play with them all, but some that I’ve come across are the minitest chef handler, chefspec, and cucumber-chef.
The lowest hanging fruit however is linting, which is where foodcritic comes in. Foodcritic parses your cookbook, and warns you about many common errors.
Food critic will yell at you about all sorts of things – if you are accessing node attributes inconsistently, if you’re passing valid ruby as a not_if string, if you’re using /tmp instead of file_cache_path, and many more. For a full list, see the github pages
Automatically running foodcritic on your public cookbooks is easy with Travis CI. Just add a .travis.yml to your repo that looks like this:
script: "gem install foodcritic -v 1.1.0 && foodcritic -f any ."
rvm:
- 1.9.3
And follow the travis getting started guide. You’ll then get an email if you commit something that isn’t quite up to par.
You can see a pivotal_workstation run on travis. We’ve still got a little ways to go to get to green, but everything it’s telling us are things we’d like to do. (pull requests welcome!)
Testing of infrastructure setup is only a matter of developer’s desire and laziness. It is very easy to develop your own solution that could fit your requirements. I have spent several hours to develop my own very lightweight alternative to cucumber-chef that doesn’t depend on amazon & hosted chef.
It is open sourced and could be found [here](https://github.com/iafonov/simple_cuke). Internally it uses bundler so it could be easily modified to use your favorite testing library. It can’t be used to test & develop separate cookbooks but it works perfectly as a regression testing tool. The object under test is node’s setup.
April 12, 2012 at 9:42 am
I agree – linting is an easy first step. Setting up full stack integration tests is next, and usually it requires thinking about how you’re going to bootstrap your infrastructure, and figuring out how to test that. I’m not sure if one cucumer/rspec/vagrant/minitest/aruba based thing is ever going to emerge as a winner, the important thing is figuring out what works for you.
The pain I’ve been feeling lately is the lack of unit tests – I want to set up preconditions and run recipes, and then set up different preconditions and run the recipes again. There’s no convenient way to do this. [gregretkowski/vmth](https://github.com/gregretkowski/vmth) was attempting to solve this problem, but it’s a hard problem to solve.
April 12, 2012 at 1:21 pm