I have been working a lot with Chef and Test kitchen lately and thus have learned a few interesting tricks when running tests with these tools. Test Kitchen is one of my favorite tools when working with Chef configuration management because it is very easy to use and has a number of powerful features that make testing things in Chef simple and easy.
Test Kitchen itself sits on top of Vagrant and Virtualbox by default so to get started with the most basic usage example of Test Kitchen you will need to have Vagrant installed along with a few other items.
- Vagrant (your distribution)
- Virtualbox (again with your distribution)
- Ruby 1.9 or higher + ruby gems
Then to install Test Kitchen.
gem install test-kitchen
That’s pretty much it. The official docs have some pretty detailed usage and in fact I have learned many of the tricks that I will be writing about today from the docs.
Once you are comfortable with Test Kitchen you can begin leveraging some of the more powerful features, which is what the remainder of this post will cover. There is a great talk given by the creator of test kitchen at this year’s Chefconf by the creator of Test Kitchen about some of the lessons learned and cool things that you can do with the tool. If you haven’t already seen it, it is worth a watch.
Anyway, let’s get started.
1) Fuzzy matching
This one is great for the lazy people out there. It basically allows you match a certain unique part of a command instead of typing out an entire command. So for example, you can just type in a partial name for a command to return the desired full command. Since Test Kitchen uses regular expression matching, this can be a very powerful feature.
2) Custom drivers
One reason that Test Kitchen is so flexible is because it can leverage many different plugins and drivers. And, since it is open source, if there is functionality missing from a driver you can simply write your own. Currently there is an awesome list of drivers available for Test Kitchen to use, and a wide variety of options available to hopefully suit most testing scenarios.
Of course, there are others as well. These just happen to be the drivers that I have tried and can verify. There is even support for alternate configuration management tool testing, which can be handy for those that are not using Chef specifically. For example there is a salt driver available.
3) .kitchen.local.yml
This is a nice handy little bit that is often overlooked but allows a nice amount of control by overriding the default .kitchen.yml configuration file with specific options. So for example, if you are using the ec2 driver in your configuration but need to test locally with Vagrant you can simply drop a .kitchen.local.yml on your dev machine and override the driver (and any other settings you might need to change). I have created the following .kitchen.local.yml for testing on a local Vagrant box using 32 bit Ubuntu to highlight the override capabilities of Test Kitchen.
driver: name: vagrant platforms: - name: ubuntu-1310-i386 - name: ubuntu-1404-i386
4) Kitchen diagnose
An awesome tool for diagnosing issues with Test Kitchen. Running the diagnose will give you lots of juicy info about what your test machines are doing (or should be doing) and a ton of configuration information about them. Basically, if something is misbehaving this is the first place you should look for clues.
If you want to blast info and settings for all your configurations, just run the following,
kitchen diagnose
5) Concurrency
If you have a large number of systems that need to have tests run on them then running your Test Kitchen tests in parallel is a great way to speed up your total testing time. Turning on concurrency is pretty straight forward, just add the “-c” flag and the number of instances to run on (the default is 9999).
kitchen converge -c 5
6) Verbose logging
This one can be helpful if your kitchen run is failing with no real clues or helpful information provided by the diagnose command. It seems obvious but getting this one to work gave me some trouble initially. To turn on verbosity simply add the debug flag to your test kitchen command.
So for example, if you want to converge a node with verbosity turned on, you would use this command.
kitchen converge -l debug
I recommend taking a look at some or all of these tricks to help improve your integration testing with Test Kitchen. Of course as I stated, all of this is pretty well documented. Even if you are already familiar with this tool, sometimes it just helps to have a refresher to remind you of a great tool and to jar your memory. Let me know if you have any other handy tricks and I will be sure to post them here.
