This is an educational cookbook, designed to show new users how to build effective tests using Chefspec, Test Kitchen, and Serverspec. It contains a very simple recipe and complete test coverage.
This cookbook supports most mainstream linux distributons. It was tested against Ubuntu 14.04 and CentOS 6.5.
The recipe attempts to install the Apache web server from the OS native package manager. Then it ensures that the webserver process is started, and ensures the web server will start at boot. Depending on a feature flag attribute set by the user, it may also write a "hello world" index.html file to the default site location for the OS.
The recipe and the accompanying tests also contain some perhaps-hasty assumptions. This was done on purpose. Finding and fixing these assumptions can be a learning exercise for the reader.
This cookbook contains a full set of Chefspec and Serverspec tests. ###The Chefspec tests The cookbook contains full coverage via Chefspec. The Chefspec tests will verify:
- That the default attributes are set correctly for the operating system
- That the correct resources for the operating system are added to the resource collection
- That the feature flag will change the behavior of the recipe in the expected way
The Chefspec test is moderately complex, and broken into several sections. It is heavily commented.
- Let assignments
- Shared example definition
- Test contexts
###The Serverspec tests The cookbook contains full coverage for Ubuntu 14.04 and CentOS 6.5 via Test Kitchen & Serverspec. The Serverspec tests are simplistic, and verify only:
- That the httpd service is running
- That the httpd service is enabled
- That the host is listening on port TCP 80
###Running the tests
To run the Chefspec tests, use the command chef exec rspec. To run the serverspec tests, run kitchen test. This will provision two new VMs, run the recipe with Chef on both VMs, then run the Serverspec tests. When the Serverspec tests pass, the VMs will automatically be destroyed. These steps can also be run manually; consult the Test Kitchen documentation or command-line help for more details.
##Lessons This cookbook is designed to impart several lessons: ###Lessons about Chefspec
- When is Chefspec testing preferable to Serverspec testing / full Chef-client converges?
- What does Chefspec actually test?
- If Chefspec doesn't actually converge a node, why is Chefspec useful?
- What things are appropriate to test with Chefspec?
###Lessons about Serverspec
- When is Serverspec testing preferable to Chefspec testing?
- What should I bother testing with Serverspec?
- What should I not bother testing with Serverspec?
###Questions to ask yourself about Chef testing Some questions to ask yourself about the tests on this cookbook and the way that coverage is built.
- Could the Chefspec tests be made less complex?
- Leaving the comments aside, Why are there so many more lines of Chefspec to test the recipe than there are in the actual recipe?
- Are all four of the contexts in the Chefspec test really necessary? Are there more contexts that should be tested? Why or why not?
- If the resource names were not dynamically generated by attributes, would it be necessary to continue testing all of the resources in Chefspec? Why or why not?
- How do Rspec shared examples work?
- How do Rspec let() calls work? Why not use local variable assignments instead?
- Why is the package installation not verified in Serverspec? Should it be? Why or why not?
- Should the service started & enabled tests be in the Serverspec test suite? Why or why not?
- Why isn't the feature flag tested in Serverspec? Should it be?
- Why aren't the index.html file contents verified in Serverspec? Should they be?
- Author:: Charles Johnson (charles@chef.io)
Copyright 20015, Chef Software, Inc.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.