kitchen-dsc 0.12.1 → 0.13.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 71cf4605d081a3739cbd3e3d451a4c599a03714574a111d523f21e55799c2f5d
-  data.tar.gz: 2623b6f7c880531b5aacd631f08f9644314a6df9959093d4dd96ae66bb8f1d38
+  metadata.gz: 66d661763e4f52b0b1f10b042d72566f4946f68475d7378955b6c0d59dba180c
+  data.tar.gz: 1e743c929da152aa6987b239dbba9f62e5bef78e528b0d4451a955b5f41066a6
 SHA512:
-  metadata.gz: 0cca4ce55da4e0a10d0f68329d458814eee9e8f028abb055663a76547fff4ccb325255dc12e6a77d8b67b4afb43d73933dae8986edd69d3b4976c557e0abe21b
-  data.tar.gz: 02f7d8210f39206396a6103069e6723295d0a5a621e3776456ded437c6aea71be5f703233090a9a0f6d022d70da1f328cecd5395f025334d2f80bf84478fda29
+  metadata.gz: c5a266a4a08fca4e824f1f242422c8f9da50c4f5f7319153f33439f070284b8d0af95289d54048a862075c3ed32d8e38339dadcc7a5a72bffd1d102daa2438df
+  data.tar.gz: 876e6da17a115df998356967c013061ab1b0d8ff5494053c6d7786c71670dfb2d38f6c443450c74308a7e9f25878e47e9db0324ac2911cce065e4722d370151e

data/.github/workflows/publish.yaml

@@ -9,13 +9,13 @@ jobs:
   release-please:
     runs-on: ubuntu-latest
     steps:
-      - uses: googleapis/release-please-action@v4
+      - uses: googleapis/release-please-action@v5
         id: release
         with:
           token: ${{ secrets.PORTER_GITHUB_TOKEN }}
 
       - name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v7
         if: ${{ steps.release.outputs.release_created }}
 
       - name: Build and publish to GitHub Package

data/.gitignore

@@ -24,3 +24,6 @@ tmp
 .yardoc
 _yardoc
 doc/
+
+# RSpec example status, used by --only-failures
+spec/examples.txt

data/.release-please-manifest.json

@@ -1,3 +1,3 @@
 {
-  ".": "0.12.1"
+  ".": "0.13.0"
 }

data/.rspec

@@ -0,0 +1,2 @@
+--require spec_helper
+--color

data/.rubocop.yml

@@ -1,11 +1,8 @@
 ---
 require:
-  - chefstyle
+  - cookstyle/chefstyle
 
 AllCops:
   TargetRubyVersion: 3.1
-  Include:
-    - "**/*.rb"
   Exclude:
     - "vendor/**/*"
-    - "spec/**/*"

data/.yamllint

@@ -0,0 +1,6 @@
+---
+extends: default
+rules:
+  line-length:
+    max: 256
+    level: warning

data/.yardopts

@@ -0,0 +1,11 @@
+--output-dir doc
+--readme README.md
+--markup markdown
+--private
+--protected
+--no-cache
+lib/**/*.rb
+-
+CHANGELOG.md
+CONTRIBUTING.md
+LICENSE

data/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Change Log
 
+## [0.13.0](https://github.com/test-kitchen/kitchen-dsc/compare/v0.12.1...v0.13.0) (2026-08-23)
+
+
+### Features
+
+* rewrite unit tests, add YARD docs and rake tasks ([#107](https://github.com/test-kitchen/kitchen-dsc/issues/107)) ([16cb07e](https://github.com/test-kitchen/kitchen-dsc/commit/16cb07ea3cbc6ed7395ccf57512d1a4cbef911a4))
+
 ## [0.12.1](https://github.com/test-kitchen/kitchen-dsc/compare/v0.12.0...v0.12.1) (2024-07-01)
 
 

data/CONTRIBUTING.md

@@ -0,0 +1,121 @@
+# Contributing to kitchen-dsc
+
+> **This project is no longer under active development** and has no active
+> maintainers. Issues filed on GitHub will most likely not be triaged. Pull
+> requests are still welcome. If you are interested in maintaining the project,
+> come and talk to us in `#test-kitchen` on
+> [Chef Community Slack](https://community-slack.chef.io/).
+
+## Reporting issues
+
+Report bugs and request features on the [issue tracker](https://github.com/test-kitchen/kitchen-dsc/issues), keeping the note above in mind. For bugs, please include:
+
+- the version of kitchen-dsc and Test Kitchen you are using
+- the WMF version on the test instance
+- your `kitchen.yml` and the DSC configuration script
+- the output of the failing command, ideally with `-l debug`
+
+## Development setup
+
+Clone the repository and install the dependencies:
+
+```sh
+git clone https://github.com/test-kitchen/kitchen-dsc.git
+cd kitchen-dsc
+bundle install
+```
+
+## Tests and linting
+
+Run everything the way CI does:
+
+```sh
+bundle exec rake          # linter + unit tests
+bundle exec rake test     # unit tests only (this is what CI runs)
+bundle exec rake style    # Cookstyle only
+bundle exec cookstyle -a  # autocorrect what can be corrected
+```
+
+The unit tests live in `spec/` and use RSpec. They build a real
+`Kitchen::Instance` around the provisioner — with the stock dummy driver,
+transport and verifier — rather than mocking it, so `default_config` blocks and
+`finalize_config!` run exactly as they do in a real converge. See
+`spec/support/kitchen_helpers.rb`.
+
+Two conventions are worth knowing before you add specs:
+
+- **Drive the public API.** Most of `Kitchen::Provisioner::Dsc` is private, but
+  every private method is reachable through `install_command`, `init_command`,
+  `create_sandbox`, `prepare_command`, `run_command` or `finalize_config!`.
+  Assert on the PowerShell those produce instead of calling private methods
+  with `send`.
+- **Match on fragments, not whole commands.** Test Kitchen wraps every command
+  with environment setup that differs between a laptop and CI (`$env:CI` is
+  only injected when `ENV["CI"]` is set), so `include` and `match` are stable
+  where `eq` is not.
+
+Useful environment variables:
+
+| Variable | Effect |
+| --- | --- |
+| `SEED=12345` | reproduce a specific random ordering |
+| `VERBOSE=1` | print full backtraces on failure |
+| `ONLY_FAILURES=1` | rerun only what failed last time |
+| `COVERAGE=false` | skip SimpleCov |
+| `RSPEC_WARNINGS=true` | enable Ruby warnings |
+
+Coverage is reported to `coverage/` after each run as a diagnostic. **It is not
+a gate** — no build fails because a percentage moved, and neither the coverage
+report nor the documentation build runs in CI.
+
+## Documentation
+
+The public API is documented with [YARD](https://yardoc.org/):
+
+```sh
+bundle exec rake yard         # build HTML docs into doc/
+bundle exec rake yard:stats   # list any undocumented objects
+bundle exec rake yard:server  # browse at http://localhost:8808
+```
+
+New methods should carry a YARD comment with `@param` and `@return` tags;
+private helpers should also be tagged `@api private`. This is a convention, not
+a CI check.
+
+## Manual testing
+
+The unit tests cover the PowerShell this gem generates and the files it stages,
+but they cannot tell you whether DSC accepts that PowerShell. Any change to the
+generated scripts should also be exercised against a real Windows instance
+running WMF 4 or newer. You will need a driver that can supply
+one, such as kitchen-vagrant, kitchen-hyperv, or kitchen-ec2.
+
+Both project layouts are worth exercising, since they take different paths
+through the provisioner:
+
+- **module style**, using `configuration_script_folder` and `configuration_script`
+- **repository style**, using `modules_path` to upload DSC resources
+
+If your change touches gallery installation, test it on a WMF 5 instance, which
+is required for `modules_from_gallery`.
+
+## Submitting changes
+
+1. Fork the repository.
+2. Create a feature branch off `main`.
+3. Make your change.
+4. Add or update specs, and run `bundle exec rake`.
+5. Push the branch to your fork and open a pull request.
+
+Please keep pull requests focused on a single change — it makes review much
+faster. Update the documentation in `README.md` when you add or change a
+configuration option.
+
+## Release process
+
+Releases are handled by the maintainers.
+
+1. Update `lib/kitchen-dsc/version.rb` with the new version.
+2. Update `CHANGELOG.md`.
+3. Merge to `main`; the [publish workflow](.github/workflows/publish.yaml) builds
+   the gem and pushes it to RubyGems.

data/Gemfile

@@ -1,24 +1,22 @@
 source "https://rubygems.org"
 
-gemspec
-
+gemspec development_group: :test
 group :development do
-  gem "countloc", "~> 0.4"
   gem "yard",      "~> 0.9", ">= 0.9.20"
+  # markdown provider for YARD
+  gem "kramdown"
   gem "pry"
   gem "pry-stack_explorer"
   gem "pry-byebug"
   gem "rb-readline"
-  gem "cane", "3.0.0"
 end
 
 group :test do
   gem "rake"
-  gem "rspec",     "~> 3.2"
-  gem "simplecov", "~> 0.9"
-  gem "minitest",  "~> 5.3"
+  gem "rspec",     "~> 3.13"
+  gem "simplecov", "~> 0.22"
 end
 
-group :chefstyle do
-  gem "chefstyle", "2.2.3"
+group :cookstyle do
+  gem "cookstyle"
 end

data/README.md

@@ -2,113 +2,201 @@
 
 [![Gem Version](https://badge.fury.io/rb/kitchen-dsc.svg)](http://badge.fury.io/rb/kitchen-dsc)
 
-A Test Kitchen Provisioner for PowerShell DSC
+A [Test Kitchen](https://kitchen.ci/) provisioner that applies [PowerShell Desired State Configuration](https://learn.microsoft.com/en-us/powershell/dsc/overview) configurations to test instances, so you can test DSC configurations and resources the same way you would test a cookbook.
 
-## Status
+> **This project is no longer under active development.** It has no active
+> maintainers. The provisioner may continue to work for some or all use cases,
+> but issues filed on GitHub will most likely not be triaged. If you are
+> interested in maintaining it, come and talk to us in `#test-kitchen` on
+> [Chef Community Slack](https://community-slack.chef.io/).
 
-This software project is no longer under active development as it has no active maintainers. The software may continue to work for some or all use cases, but issues filed in GitHub will most likely not be triaged. If a new maintainer is interested in working on this project please come chat with us in #test-kitchen on Chef Community Slack.
+<!-- -->
+
+> This documentation uses [Cinc Workstation](https://cinc.sh/) and the `cinc` commands throughout. Everything here works identically with Chef Workstation — see [Using with Chef](#using-with-chef).
 
 ## Requirements
 
-You'll need a driver box with WMF4 or greater (ONLY WINDOWS SYSTEMS)
+- **Windows test instances only.** The instance must be running WMF 4 or newer.
+- A Test Kitchen driver that can provide Windows instances, such as
+  [kitchen-vagrant](https://github.com/test-kitchen/kitchen-vagrant),
+  [kitchen-hyperv](https://github.com/test-kitchen/kitchen-hyperv), or
+  [kitchen-ec2](https://github.com/test-kitchen/kitchen-ec2)
+- WMF 5 if you want to install modules from a PowerShell gallery
+
+## Installation
+
+Add the provisioner to your `Gemfile` alongside Test Kitchen and a driver:
+
+```ruby
+gem "test-kitchen"
+gem "kitchen-dsc"
+gem "kitchen-vagrant"
+```
+
+Then:
+
+```sh
+bundle install
+```
+
+Or install it directly:
+
+```sh
+gem install kitchen-dsc
+```
+
+## Two ways to lay out a project
+
+How you configure this provisioner depends on what you are testing.
+
+**Module style** keeps the DSC configuration next to the module it exercises.
+Point `configuration_script_folder` and `configuration_script` at that file.
+
+**Repository style** keeps a `modules` directory of DSC resources at the root of
+the repository, which the provisioner uploads to the instance before applying
+the configuration. `modules_path` controls where that directory is.
+
+Worked examples of each:
+
+- [Repository style testing](https://github.com/smurawski/dsc-kitchen-project)
+- [Module style testing](https://github.com/powershellorg/cwebadministration/tree/smurawski/adding_tests)
+
+## Quick Start
+
+Put a DSC configuration in `examples/dsc_configuration.ps1`, then:
+
+```yaml
+---
+driver:
+  name: vagrant
+
+provisioner:
+  name: dsc
+  dsc_local_configuration_manager_version: wmf5
+
+platforms:
+  - name: windows-2022
+
+suites:
+  - name: default
+```
+
+Then run the full test cycle:
+
+```sh
+cinc kitchen test
+```
+
+Or step through it:
+
+```sh
+cinc kitchen create    # build the Windows instance
+cinc kitchen converge  # apply the DSC configuration
+cinc kitchen verify    # run your tests
+cinc kitchen destroy   # remove the instance
+```
+
+By default the provisioner looks for a configuration named after the suite, in
+`examples/dsc_configuration.ps1`.
+
+> **Note on output timing:** the verbose stream is returned after the DSC job
+> completes rather than while it runs, because WMF versions differ in how they
+> expose that stream. Expect a delay before you see run details.
 
-## Installation & Setup
+## Configuration
 
-You'll need the test-kitchen & kitchen-dsc gems installed in your system, along with kitchen-vagrant or some ther suitable driver for test-kitchen.
+All options below are set under the `provisioner:` key in `kitchen.yml`, or per suite under `suites[].provisioner:`.
 
-### Note
+### Configuration script
 
-You will see a delay in the return of the run details due to an difference in how the verbose stream is returned for DSC runs between WMF versions, so I return the verbose stream after the job completes.  I'd love to live stream the results, but that'll take a bit more experimentation. (PR's welcome!)
+| Option | Default | Description |
+| --- | --- | --- |
+| `configuration_script_folder` | `"examples"` | Directory holding the PowerShell script(s) that define the DSC configuration. |
+| `configuration_script` | `"dsc_configuration.ps1"` | Name of the PowerShell script containing the DSC configuration command, and possibly its configuration data. |
+| `configuration_name` | the suite name | Name of the configuration command to run. |
 
-## Example Configurations
+### Configuration data
 
-* [Repository Style Testing](https://github.com/smurawski/dsc-kitchen-project)
-* [Module Style Testing](https://github.com/powershellorg/cwebadministration/tree/smurawski/adding_tests)
+| Option | Default | Description |
+| --- | --- | --- |
+| `configuration_data` | *unset* | YAML representation of the data passed to the configuration. Overrides any configuration data assigned in the script itself. |
+| `configuration_data_variable` | `"ConfigurationData"` | Name of the variable holding the ConfigurationData hashtable. Can be set here or defined in the configuration script. |
 
-## Configuration Settings
+### Local Configuration Manager
 
-* configuration_script_folder
-  * Defaults to 'examples'.
-  * The location of a PowerShell script(s) containing the DSC configuration command(s).
+| Option | Default | Description |
+| --- | --- | --- |
+| `dsc_local_configuration_manager_version` | `"wmf4"` | Which LCM is in place. Also accepts `wmf4_with_update` and `wmf5`. |
+| `dsc_local_configuration_manager` | *see below* | Hash of LCM settings. |
 
-* configuration_script
-  * Defaults to 'dsc_configuration.ps1'
-  * The name of the PowerShell script containing the DSC configuration command(s) (and possibly configuration data)
+`wmf4_with_update` means WMF 4 with KB3000850 applied, which adds support for
+configurations generated by WMF 5 along with a number of fixes. Today the only
+differences between `wmf4` and the other two values are the `action_after_reboot`
+and `debug_mode` settings.
 
-* configuration_name
-  * Name of the configuration to run, defaults to the suite name.
+The LCM settings and their defaults:
 
-* configuration_data
-  * A YAML representation of what should be passed to the configuration.
-  * Overrides any configurationdata variable assigned in the configuration script.
+| Setting | Default | Notes |
+| --- | --- | --- |
+| `action_after_reboot` | `"StopConfiguration"` | `wmf4_with_update` and `wmf5` only. |
+| `reboot_if_needed` | `false` | |
+| `allow_module_overwrite` | `false` | |
+| `certificate_id` | `nil` | |
+| `configuration_mode` | `"ApplyAndAutoCorrect"` | |
+| `configuration_mode_frequency_mins` | `30` | `15` on `wmf5`. |
+| `debug_mode` | `"All"` | `wmf4_with_update` only. |
+| `refresh_frequency_mins` | `15` | `30` on `wmf5`. |
+| `refresh_mode` | `"PUSH"` | |
 
-* configuration_data_variable
-  * Defaults to 'ConfigurationData'
-  * Name of the variable that contains the ConfigurationData hashtable
-  * Can be defined in the configuration script or via the `configuration_data` configuration setting.
+### Modules from a gallery
 
-* dsc_local_configuration_manager_version
-  * Defaults to 'wmf4'
-  * Identifies what version of the LCM is in place
-  * Other valid values are 'wmf4_with_update' and 'wmf5'
-    * Currently the only difference between wmf4 and wmf4_with_update/wmf5 is the action_after_reboot and the debug_mode settings.  Eventually, I'd like to add support for partial configurations, pull servers, etc..
-  * In this context, wmf4_with_update refers to wmf4 with KB3000850 applied (to add support for WMF 5 generated configurations, plus some fixes).
+Installing modules from a gallery requires WMF 5 on the instance.
 
-* dsc_local_configuration_manager
-  * Settings for the LCM
-  * Defaults are:
-    * action_after_reboot = 'StopConfiguration' # wmf4_with_update or wmf5
-    * reboot_if_needed = false
-    * allow_module_overwrite = false
-    * certificate_id = nil
-    * configuration_mode = 'ApplyAndAutoCorrect'
-    * configuration_mode_frequency_mins = 30    # 15 on wmf5
-    * debug_mode = 'All'                        # wmf4_with_update
-    * refresh_frequency_mins = 15               # 30 on wmf5
-    * refresh_mode = 'PUSH'
+| Option | Default | Description |
+| --- | --- | --- |
+| `modules_from_gallery` | *unset* | Modules to install from a gallery. A string for one module, an array for several, or a hash matching the parameters of `Install-Module`. `Name` is required; `Force` is always applied and need not be given. |
+| `gallery_name` | *unset* | Name of a custom PowerShell gallery to install from. If no package source with this name is registered on the machine, `gallery_uri` must be set too. |
+| `gallery_uri` | *unset* | URI of a custom PowerShell gallery feed. |
+| `nuget_force_bootstrap` | `true` | Bootstrap the NuGet package provider for PowerShell PackageManagement before installing modules. |
 
-* modules_from_gallery
-  * Requires WMF 5
-  * Takes a string (for one module) or an array (for multiple) to install from the gallery
-  * Or takes a hash with keys matching the parameters for install-module.
-    * Name is required.
-    * Force is automatically used and not required as part of the hash table.
-    * Repository defaults to either PSGallery or any custom feed defined, but can be overriden here.
+### Repository style testing
 
-* gallery_name
-  * Custom PowerShell gallery name to install modules from.
-  * If there is no package source with this name registered on the machine, then gallery_uri must be configured as well.
+| Option | Default | Description |
+| --- | --- | --- |
+| `modules_path` | `"modules"` | Directory of modules containing DSC resources to upload to the instance, relative to the root of the repository, next to `kitchen.yml`. |
 
-* gallery_uri
-  * URI for a custom PowerShell gallery feed.
+### Reboot handling
 
-### Specific to repository style testing
+These are standard Test Kitchen provisioner options that this provisioner gives DSC-specific defaults.
 
-* modules_path
-  * Defaults to 'modules'.
-  * Points to the location of modules containing DSC resources to upload
-  * This path is relative to the root of the repository (the location of the .kitchen.yml).
+| Option | Default | Description |
+| --- | --- | --- |
+| `retry_on_exit_code` | `[35]` | Exit codes that cause the converge to be retried. Exit code 35 is DSC signalling that a reboot is required. |
+| `max_retries` | `3` | Number of times to retry the converge on one of those exit codes. |
+| `root_path` | driver default | Directory on the instance where the configuration and modules are staged. |
 
-## Example
+## Examples
+
+### Module style, with modules from a custom gallery
 
 ```yaml
 provisioner:
-  - name: dsc
-    dsc_local_configuration_manager_version: wmf5
-    dsc_local_configuration_manager:
-      reboot_if_needed: true
-      debug_mode: none
-    configuration_script_folder: .
-    configuration_script: SampleConfig.ps1
-    gallery_uri: https://ci.appveyor.com/nuget/xWebAdministration
-    gallery_name: xWebDevFeed
-    modules_from_gallery:
-      - xWebAdministration
-      - name: xComputerManagement
-        requiredversion: 1.4.0.0
-        repository: PSGallery
-
-suite:
+  name: dsc
+  dsc_local_configuration_manager_version: wmf5
+  dsc_local_configuration_manager:
+    reboot_if_needed: true
+    debug_mode: none
+  configuration_script_folder: .
+  configuration_script: SampleConfig.ps1
+  gallery_uri: https://ci.appveyor.com/nuget/xWebAdministration
+  gallery_name: xWebDevFeed
+  modules_from_gallery:
+    - xWebAdministration
+    - name: xComputerManagement
+      requiredversion: 1.4.0.0
+      repository: PSGallery
+
+suites:
   - name: test
     provisioner:
       configuration_data:
@@ -116,3 +204,66 @@ suite:
           - nodename: localhost
             role: webserver
 ```
+
+### Repository style
+
+```yaml
+provisioner:
+  name: dsc
+  dsc_local_configuration_manager_version: wmf5
+  modules_path: modules
+  configuration_script_folder: examples
+  configuration_script: webserver.ps1
+  configuration_name: WebServer
+```
+
+### Allowing reboots during a converge
+
+```yaml
+provisioner:
+  name: dsc
+  dsc_local_configuration_manager_version: wmf5
+  dsc_local_configuration_manager:
+    reboot_if_needed: true
+    action_after_reboot: ContinueConfiguration
+  max_retries: 5
+```
+
+### Per-suite configuration data
+
+```yaml
+provisioner:
+  name: dsc
+  configuration_script_folder: examples
+  configuration_script: webserver.ps1
+
+suites:
+  - name: default
+    provisioner:
+      configuration_data:
+        AllNodes:
+          - nodename: localhost
+            role: webserver
+  - name: minimal
+    provisioner:
+      configuration_data:
+        AllNodes:
+          - nodename: localhost
+            role: minimal
+```
+
+## Using with Chef
+
+This provisioner is not tied to Cinc, and it does not require Cinc or Chef on the instance at all — it applies DSC configurations directly. The commands above use Cinc Workstation; with [Chef Workstation](https://www.chef.io/downloads/tools/workstation) run `kitchen` instead of `cinc kitchen`. No provisioner configuration changes are needed.
+
+## Contributing
+
+This project has no active maintainers, so please read the status note at the
+top before opening an issue. Pull requests are still welcome on
+[GitHub](https://github.com/test-kitchen/kitchen-dsc). See
+[CONTRIBUTING.md](CONTRIBUTING.md) for development setup and the state of the
+test tooling.
+
+## License
+
+Licensed under the Apache License, Version 2.0. See [LICENSE](LICENSE) for details.

data/Rakefile

@@ -1,21 +1,56 @@
+# frozen_string_literal: true
+
 require "bundler/gem_tasks"
-require "chefstyle"
+
+require "cookstyle/chefstyle"
 require "rubocop/rake_task"
 
 RuboCop::RakeTask.new(:style) do |task|
   task.options += ["--display-cop-names", "--no-color"]
 end
 
-# Create the spec task.
 require "rspec/core/rake_task"
+
+# Named `test` because the shared test-kitchen CI workflow invokes
+# `bundle exec rake test`. Renaming it would break CI.
 RSpec::Core::RakeTask.new(:test, :tag) do |t, args|
   t.rspec_opts = [].tap do |a|
-    a << "--color"
     a << "--format #{ENV["CI"] ? "documentation" : "progress"}"
     a << "--backtrace" if ENV["VERBOSE"] || ENV["DEBUG"]
     a << "--seed #{ENV["SEED"]}" if ENV["SEED"]
     a << "--tag #{args[:tag]}" if args[:tag]
-    a << "--default-path test"
-    a << "-I test/spec"
+    a << "--only-failures" if ENV["ONLY_FAILURES"]
   end.join(" ")
 end
+
+# YARD lives in the :development bundle group, which a test-only install may
+# skip. Documentation tasks are optional, so degrade rather than break `rake`.
+begin
+  require "yard"
+
+  YARD::Rake::YardocTask.new(:yard) do |t|
+    t.stats_options = ["--list-undoc"]
+  end
+
+  namespace :yard do
+    desc "Report documentation coverage, listing undocumented objects"
+    task :stats do
+      sh "yard stats --list-undoc"
+    end
+
+    desc "Serve the docs at http://localhost:8808, reloading on change"
+    task :server do
+      sh "yard server --reload"
+    end
+  end
+rescue LoadError
+  %w{yard yard:stats yard:server}.each do |name|
+    desc "(unavailable: install the :development bundle group)" if name == "yard"
+    task name do
+      abort "YARD is not available. Run `bundle install --with development`."
+    end
+  end
+end
+
+desc "Run the linter and the unit tests"
+task default: %i{style test}