Using Test-Kitchen for Local Testing
Test Kitchen performs integration tests on one or more platforms in an isolated environment that has been configured from a Chef cookbook.
Join the DZone community and get the full member experience.Join For Free
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
driver_nameis 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
driverto override the default driver for that platform or suite; a driver specified for a suite will override a driver set for a platform.
provisioner_namespecifies how the chef-client will be simulated during testing.
chef_soloare the most common provisioners used for testing cookbooks.
platform-versionis 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.)
suiteis a collection of test suites, with each
suite_namegrouping defining an aspect of a cookbook to be tested. Each
suite_namemust specify a
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
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 loginfrom 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:
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.
Published at DZone with permission of , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.