6.1 KiB
Testing the macOS Cookbook
Requirements
Syntax and style
cookstyle
andfoodcritic
Syntax testing is pretty straight forward. At the root of the cookbook, run:
cookstyle
foodcritic .
Unit tests
For unit tests, we focus on testing the library files, which are written
in pure Ruby and tested with RSpec. The library files contain most of the core
business logic for each of the custom resources and are used as either mixins
for the custom resources or contain classes that act as helpers, except with
explicit namespacing. Some libary files are heavily unit tested, others are definitely
missing much-needed unit test coverage. The following command syntax assumes
you've made the ChefDK rspec
your default by running chef shell-init bash
(https://docs.chef.io/ctl_chef.html#chef-shell-init)
Clone this repo and in the root of the cookbook, run:
rspec spec
To run the unit tests in a specific file:
rspec spec/unit/libraries/xcode_spec.rb
Integration tests
For integration tests, we test custom resources using a test cookbook, found in
test/cookbooks/macos_test
.
In general, each of the custom resources is used in a corresponding test recipe,
which is then added to a corresponding suite's runlist. For example, the xcode
resource is used in the xcode.rb
recipe, which is called in the xcode
suite.
For the specific suite, there are corresponding integration tests as specified
in the suite. Every suite is tested against all three platform version.
Building a macOS Vagrant Box
Due to Apple's Software License Agreement, you'll need to build your own boxes. There's a number of different resources on GitHub that provide some really great guides, but we're partial to osx-vm-templates.
This procedure is a bit of a pain to really nail down. We've been working on refining and automating it as much as possible, but regular changes to the macOS operating system by Apple (e.g. signing restrictions introduced in 10.12.3) have made this challenging.
Read the osx-vm-templates README thouroughly to get a clear understanding of what needs to be done to turn a "vanilla" macOS installer into a shiny new, barely-touched macOS Vagrant base box. The process is pretty different depending on which version you're building, so tread lightly.
It should be noted that we also maintain a fork of osx-vm-templates that contains a revised README and better support for building Parallels Desktop Vagrant boxes. We're working on getting those changes implemented, but there is a few issues that need to be addressed before doing so.
Running the tests
Once you have finished building and "adding" your box (with vagrant box add
),
you'll need to modify the .kitchen.yml
. The only modifications you should
need to make are replacing our box names with yours. For example, you would
replace apex/macos-10.13.6
with my_high_sierra_box
. To double check the
available boxes and their names, execute vagrant box list
. For example:
$ vagrant box list
apex/macos-10.12.6 (parallels, 2.0.0)
apex/macos-10.13.6 (parallels, 1.1.0)
Next, make sure you're in the macOS cookbook root and run kitchen list
to view
the available instances. It should look something like this:
$ kitchen list
Instance Driver Provisioner Verifier Transport Last Action Last Error
default-apex-macos-10136 Vagrant ChefZero Inspec Ssh <Not Created> <None>
default-apex-macos-10126 Vagrant ChefZero Inspec Ssh <Not Created> <None>
xcode-apex-macos-10136 Vagrant ChefZero Inspec Ssh <Not Created> <None>
xcode-apex-macos-10126 Vagrant ChefZero Inspec Ssh <Not Created> <None>
spotlight-apex-macos-10136 Vagrant ChefZero Inspec Ssh <Not Created> <None>
spotlight-apex-macos-10126 Vagrant ChefZero Inspec Ssh <Not Created> <None>
certificate-apex-macos-10136 Vagrant ChefZero Inspec Ssh <Not Created> <None>
certificate-apex-macos-10126 Vagrant ChefZero Inspec Ssh <Not Created> <None>
The kitchen list
command serves as a nearly-perfect way to validate the
.kitchen.yml
syntax. For more info, check out kitchen help
for commands and
run kitchen help COMMAND
for help on a specific subcommand. When you're ready,
run kitchen test
.
kitchen test
kitchen
supports using regular expressions to only run a specific instance.
For example:
kitchen test xcode # test the xcode suite on all versions
kitchen test default.*101[23] # only test default suites on 10.12 and 10.13
macOS takes a little while to boot and the suites themselves (especially Xcode)
can take a while to run - some of our builds end up being 30-40 minutes per operating
system. If you've got the hardware, don't be afraid to run
kitchen test --concurrency n
to save a little time (where n
is the number of concurrent
instances you want to boot up).
Rake Tasks
Included are some convenient rake tasks for running particular batteries of tests. Just run rake
to see a list of tasks available.
Continuous testing with guard
We've included a Guardfile custom-tailored to run the appropriate unit tests whenever a file is modified. To get started, simply bundle install && rake test:guard
and watch the appropriate tests run automatically as you edit source files!