$ kitchen init --driver=kitchen-vagrant
- driver: This is where we configure the behaviour of the Kitchen Driver - the component that is responsible for creating a machine that we'll use to test our cookbook. Here we set up basics like credentials, ssh usernames, sudo requirements, etc. Each Driver is responsible for requiring and using the configuration here. Under this section we have driver.name: This tells Test Kitchen that we want to use the kitchen-vagrant driver by default unless otherwise specified.
- provisioner: This tells Test Kitchen how to run Chef, to apply the code in our cookbook to the machine under test. The default and simplest approach is to use chef-solo, but other options are available, and ultimately Test Kitchen doesn't care how the infrastructure is built - it could theoretically be with Puppet, Ansible, or Perl for all it cares.
- platforms: This is a list of operation systems on which we want to run our code. Note that the operating system's version, architecture, cloud environment, etc. might be relevant to what Test Kitchen considers a Platform.
- suites: This section defines what we want to test. It includes the Chef run-list and any node attribute setups that we want run on each Platform above. For example, we might want to test the MySQL client cookbook code seperately from the server cookbook code for maximum isolation.
$ kitchen list
$ kitchen create default-ubuntu-1204
$ kitchen converge default-ubuntu-1204
$ kitchen login default-ubuntu-1204
$ kitchen verify default-ubuntu-1204
$ kitchen test default-ubuntu-1204
- Destroys the instance if it exists (Cleaning up any prior instances of )
- Creates the instance (Creating )
- Converges the instance (Converging )
- Sets up Busser and runner plugins on the instance (Setting up )
- Verifies the instance by running Busser tests (Verifying )
- Destroys the instance (Destroying )
A few details with regards to test:
- Test Kitchen will abort the run on the instance at the first sign of trouble. This means that if your Chef run fails then Busser won't be installed and the instance won't be destroyed. This gives you a chance to inspect the state of the instance and fix any issues.
- The behavior of the final destroy action can be overridden if desired. Check out the documentation for the --destroy flag using kitchen help test.
- The primary use case in mind for this meta-action is in a Continuous Integration environment or a command for developers to run before check in or after a fresh clone. If you're using this in your test-code-verify development cycle it's going to quickly become very slow and frustrating. You're better off running the converge and verify subcommands in development and save the test subcommand when you need to verify the end-to-end run of your code.