# Testing the macOS Cookbook - [Syntax and style](#syntax-and-style) - [Unit tests](#unit-tests) - [Integration tests](#integration-tests) - [Rake Tasks](#rake-tasks) ## Requirements - [ChefDK](https://downloads.chef.io/chefdk) - [Vagrant](https://www.vagrantup.com/) - [Packer](https://www.packer.io/) - A supported macOS hypervisor: - [Parallels](https://www.parallels.com/landingpage/pd/general/) - [VirtualBox](https://www.virtualbox.org/wiki/Downloads) - [VMWare Fusion](https://www.vmware.com/products/fusion.html) ## Syntax and style - `cookstyle` and `foodcritic` Syntax testing is pretty straight forward. At the root of the cookbook, run: ```shell 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: ```shell rspec spec ``` To run the unit tests in a specific file: ```shell 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`](https://github.com/Microsoft/macos-cookbook/tree/master/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](https://github.com/timsutton/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](https://github.com/timsutton/osx-vm-templates/blob/master/README.md) 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](https://github.com/americanhanko/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: ```shell $ 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: ```shell $ kitchen list Instance Driver Provisioner Verifier Transport Last Action Last Error default-apex-macos-10136 Vagrant ChefZero Inspec Ssh default-apex-macos-10126 Vagrant ChefZero Inspec Ssh xcode-apex-macos-10136 Vagrant ChefZero Inspec Ssh xcode-apex-macos-10126 Vagrant ChefZero Inspec Ssh spotlight-apex-macos-10136 Vagrant ChefZero Inspec Ssh spotlight-apex-macos-10126 Vagrant ChefZero Inspec Ssh certificate-apex-macos-10136 Vagrant ChefZero Inspec Ssh certificate-apex-macos-10126 Vagrant ChefZero Inspec Ssh ``` 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`. ```shell kitchen test ``` `kitchen` supports using regular expressions to only run a specific instance. For example: ```shell 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!