Using Test-Kitchen for Local Testing

Test Kitchen is used mainly for integration testing for your Chef Cookbooks, but it can also be used to isolate application bugs in a local environment. It is the best method to test and debug your application or infrastructure code locally using virtual technologies. Test Kitchen can converge Chef cookbooks across various combinations of platforms (operating systems). The most important aspect of this local testing framework is that it's a self-service tool anyone can use at any given time.

Fifty-Thousand Foot View of Test Kitchen

The sole purpose of Test Kitchen is to perform integration tests on one or more platforms in an isolated environment that has been configured from a Chef cookbook. A cookbook is used to handle the download, install, and setup of a particular service, application, or functionality. For instance, a cookbook can be created to download and install Android SDK to build and test an Android app locally. The test environments are defined in a single kitchen.yml file located inside the Chef cookbook source control repository (I will touch more on the structure of this file in the next section). The test harness supports various platforms, like CentOS, Ubuntu, Windows, and more. To deploy these different platforms locally, Test Kitchen will use two virtualization tools: Vagrant and VirtualBox. Test Kitchen also supports multiple Ruby testing frameworks from Bats, Minitest, Rspec, Serverspec, and more.

How to Set Up a Test Kitchen Environment

Before we start learning how to set up an environment using Test Kitchen, you need to be able to answer the following two questions below:

• Which targeted platforms and versions will your service, application or functionality need to support?
• How are you going to manage virtual machine images?

Your organization needs to privately host the supported virtual machine images for development and testing. Please don't use public virtual machine images to configure your organization. Why wouldn't we want to do that?

The first things that come to mind are the possible security risks. I recommend using Hashicorp to manage your private virtual machine images.

To get started, a .kitchen.yml needs to be created at the root of your Chef cookbook. This file stores all the information on how and what to test. Let's now start walking through the structure of the kitchen.yml file.

• The driver_name is the name of a driver that will be used to create platform instances used during cookbook testing. This is the default driver used for all platforms and suites unless a platform or suite specifies a driver to override the default driver for that platform or suite; a driver specified for a suite will override a driver set for a platform.
• The provisioner_name specifies how the chef-client will be simulated during testing. chef_zero and chef_solo are the most common provisioners used for testing cookbooks.
• The platform-version is the name of the platform on which Kitchen will perform cookbook testing. (For example, Ubuntu-14.04 or Centos-7.2, depending on the platform.)
• The suite is a collection of test suites, with each suite_name grouping defining an aspect of a cookbook to be tested. Each suite_name must specify a run-list.

Here's what the kitchen configuration file should look like:

---
driver:
  name: vagrant # driver_name

provisioner:
  name: chef_zero # provisoner_name

platforms:
  - name: centos-7.2 # platform_name
  - name: ubuntu-14.04 # platform_name

suites:
  - name: default
    run_list:
      - recipe[gd-test-helper]
      - recipe[android-sdk::default]
    ...

Here is a great reference document on how to configure the kitchen.yml file.

Local Testing

Now that we have completed the review of the kitchen file structure, it’s time to execute a few test kitchen commands.

For instance, we need to debug an application bug reported on a local environment.

• To converge a particular instance, we would run kitchen converge centos-7.2.
• When the converge has completed, we log into the converge instanced by running kitchen login from command. Now we're ready to execute some tests to reproduce the application bug reported.

Here is a list of kitchen commands we can use for testing or debugging:

Conclusion

We've covered how to use Test Kitchen as a self-service tool for testing and debugging services, applications, or functionality locally. Find the time to understand the tool inside out. It is a great tool for teams automating their infrastructure code and speeds up the QA cycle. It allows us to automate the testing process, check, and debug infrastructure code.