pdqtest 1.4.1 → 1.9.9beta2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: f1072480f75eea0f413ce0ca6892b0225f4ff19e269840a8c81c3531880f4943
-  data.tar.gz: 79375cec8ca0e22a87c159b04318af11f01521bdbfffd69d7f71f006f5f52772
+  metadata.gz: 133ce9046197e77d059c3096f234f584869345117cc5bb4e390d4dadca28e0c8
+  data.tar.gz: e49e82c1178044f981dcfb4d07a7549918acbe0e04d9d96f58ead72031a529a6
 SHA512:
-  metadata.gz: 6888c949b26d54dcfa4ddd3040377d2a34a7927be72cbe9474da7a5f4e136fc0fbde146a75523dee16c5f021ac5cef99d82da4b35872b32f924b727e1826a288
-  data.tar.gz: 01db8353e42af879787ceba8528361808c0e1beb68ccf1ee7dc4e05ecebf99e3f7f9ca3561aa6b92a70288dbc828e9dfc91bb95427dc51f5d000904465b03de1
+  metadata.gz: 0be32828cc23fa885eb8876cb66bd8da89e5a2e18ba1f3173c7fd76bc7b32034011a723903533ec046f7af3dcd4f4b1f9d01f08d91bb0fef498169b8aaae37cc
+  data.tar.gz: 974ad82acd6cbeaf3f02df995eb422386a68843b9708f72b7ad610105e4fc06bafc8e9bb2f38967f931cb662d4aab3a598c44cec33985335ed59d2b5618dd00b

data/.travis.yml

@@ -3,6 +3,12 @@ language: ruby
 services:
   - docker
 rvm:
-  - 2.3.3
-before_install: gem install bundler
-script: "bundle exec pdqtest setup && bundle exec rake spec"
+  - 2.5.1
+before_install:
+  - wget https://apt.puppetlabs.com/puppet5-release-trusty.deb
+  - sudo dpkg -i puppet5-release-trusty.deb
+  - sudo apt-get update
+  - sudo apt install -y pdk
+  - gem install bundler
+script:
+  - bundle exec pdqtest setup && bundle exec rake spec

data/doc/acceptance_tests.md

@@ -1,37 +1,65 @@
 # Acceptance tests
 * Acceptance tests run within a Docker container managed by PDQTest
 * The Docker container breaks all the rules of Docker and runs a full version of Systemd to allow complete testing of Puppet code in the most portable way (basically treat docker as a high speed VM)... This is deliberate - PDQTest exists to get results, not be a perfect Docker app.
-* There are two supported docker images - Centos 7 and Ubuntu 16.04
+* There are three supported docker images:
+    * Centos 7
+    * Ubuntu 16.04
+    * Windows (microsoft/windowsservercore)
 * Centos is used by default
 * Ubuntu will be used if your `metadata.json` declares compatibility with Ubuntu
-* Centos is great for mocking systems like AIX... if you replace OS binaries as required in the `__setup.sh` scripts
-* No idea what to do to test windows on linux :/ containers seem out of the question and VMs would involve licensing
-* If you have a specific container you want to use, pass `--image-name` on the command line, it accepts a comma delimited list of image names to test on
-* The container will only be started if at least one example file is present **and contains the correct magic marker**
-* You can get a shell on the docker container if needed, see [Debugging failed builds](#debugging-failed-builds)
+* Windows will be used if your `metadata.json` declares compatibility with 
+  Windows
+* Centos is great for mocking systems like AIX... if you replace OS binaries as
+  required in the `__setup.sh` scripts
+* If you have a specific container you want to use, pass `--image-name` on the
+  command line, it accepts a comma delimited list of image names to test on
+* The container will only be started if at least one example file is present 
+  **and contains the correct magic marker**
+* You can get a shell on the docker container if needed, see 
+  [Debugging failed builds](#debugging-failed-builds)
 * See the [docker_images](../docker_images) folder for examples
 
 ### Test workflow
-1. Scan for all example files under `/examples`.  Files must end in `.pp` and contain the magic marker `#@PDQTest` to be processed
+1. Scan for all example files under `/examples`.  Files must end in `.pp` and 
+   contain the magic marker `#@PDQTest` or `#@PDQTestWin` to be processed
 2. If example files are present, start the docker container
 3. For each example file:
-  * Check for a file at `/spec/acceptance/EXAMPLE_NAME__setup.sh`,   If it exists, run it inside the container.  This is a useful place to install preqrequisites, edit files, install mock services, clean up after other tests, etc.
-  * Check for a file at `/spec/acceptance/EXAMPLE_NAME__before.bats`, If it exists run BATS against it.  This is normally used to check the system state is clean or that any test prerequisites have been setup correctly
-  * Run `puppet apply` on the example file twice
-  * Check for a file at `/spec/acceptance/EXAMPLE_NAME.bats`, If it exists run BATS against it.  This is normally used to check the state of the system after running puppet.  You can do things like check services are running, check files edited correctly, or basically anything that you can write in bash!
+  * Check for a file at `/spec/acceptance/EXAMPLE_NAME__setup.(sh|ps1)`, If it
+    exists, run it inside the container.  This is a useful place to install 
+    preqrequisites, edit files, install mock services, clean up after other
+    tests, etc.
+  * Check for a file at `/spec/acceptance/EXAMPLE_NAME__before.(bats|pats)`, If
+    it exists run BATS or PATS against it.  This is normally used to check the
+    system state is clean or that any test prerequisites have been setup 
+    correctly
+  * Run `puppet apply` on the example file twice (to check idempotency)
+  * Check for a file at `/spec/acceptance/EXAMPLE_NAME.(bats|pats)`, If it 
+    exists run BATS against it.  This is normally used to check the state of the
+    system after running puppet.  You can do things like check services are
+    running, check files edited correctly, or basically anything that you can
+    write in bash!
 4. Destroy the container unless we were asked to keep it with `--keep-container`
 
-Note: `EXAMPLE_NAME` is the example filename minus the directory and `.pp`, eg the `EXAMPLE_NAME` for `examples/foo.pp` would just be `foo`.
+Note: `EXAMPLE_NAME` is the example filename minus the directory and `.pp`, eg
+the `EXAMPLE_NAME` for `examples/foo.pp` would just be `foo`.
 
 ### Example files
 * Found inside `/examples`
 * Regular puppet code
 * Will be executed _twice_ (to check for idempotency) with `puppet apply`
-* _MUST_ contain the magic marker `#@PDQTest` on a line at the top of the file to indicate that this test should be processed by PDQTest
-* Basically the same as a regular puppet [smoke test](https://docs.puppet.com/puppet/latest/tests_smoke.html#module-smoke-testing) but run automatically and with system state tests
+* _MUST_ contain the magic marker `#@PDQTest` or `#@PDQTestWin` on a line at the
+  top of the file to indicate that this test should be processed by PDQTest
+* Basically the same as a regular puppet 
+  [smoke test](https://docs.puppet.com/puppet/latest/tests_smoke.html#module-smoke-testing) but run automatically and with system state tests
 
 ### BATS tests
-If you've never seen a BATS test before and have previously been writing server spec code, you'll probably kick youself when you see how simple they are.  Here's an example:
+If you've never seen a [BATS](https://github.com/bats-core/bats-core) test 
+before and have previously been writing server spec code, you'll probably kick
+youself when you see how simple they are.
+
+BATS lets you run tests anywhere you can run BASH.
+
+Here's an example:
 
 ```BASH
 # Tests are really easy! just the exit status of running a command...
@@ -41,9 +69,13 @@ If you've never seen a BATS test before and have previously been writing server
 }
 ```
 
-Tests are all written in BASH and the testcase passes if the stanza returns zero.  This means that basically any Linux/Unix sysadmin is now empowered to write Testcases and do TDD - score!
+Tests are all written in BASH and the testcase passes if the stanza returns 
+zero.  This means that basically any Linux/Unix sysadmin is now empowered to 
+write Testcases and do TDD - score!
 
-Since our tests are written in BASH, there are of course all the usual bash quirks such as failing on incorrect spacing, bizzare variable quoting etc, but given the simplicity gained its a worthwhile tradeoff.
+Since our tests are written in BASH, there are of course all the usual bash 
+quirks such as failing on incorrect spacing, bizzare variable quoting etc, 
+but given the simplicity gained its a worthwhile tradeoff.
 
 Consider the following (real) test:
 
@@ -53,10 +85,43 @@ Consider the following (real) test:
 }
 ```
 
-Here, we have done exactly what it looks like we have done - checked for the value of a particular setting in a text file.  Since our tests our plain old BASH, it means we can do things like test daemons are running with `systemctl`, test ports are open with `netstat` and do complete system tests `wget` and `curl`.  Cool!
+Here, we have done exactly what it looks like we have done - checked for the 
+value of a particular setting in a text file.  Since our tests our plain old 
+BASH, it means we can do things like test daemons are running with `systemctl`,
+test ports are open with `netstat` and do complete system tests `wget` and 
+`curl`.  Cool!
+
+### PATS tests
+[PATS](https://github.com/declarativesystems/pats) is to testing with PowerShell
+as BATS is to testing with BASH. PATS is currently experimental and lets you
+write your tests using the same syntax as BATS but with the body of the tests
+being executed with PowerShell. As always, the exit status of your PowerShell
+fragment is the result of the test. Here's an example that tests the timezone
+has been set as desired. In this case we have shelled out to run `cmd.exe` but
+you could just run pure PowerShell if you like:
+
+```
+@test "sets the timezone correctly" {
+  cmd /C "tzutil /g | findstr /C:`"New Zealand Standard Time`" "
+}
+```
+
+PATS is used for testing on Windows.
+
+#### What if my project needs testing on Windows and Linux?
+At present you would need to run `pdqtest` twice - once in a Windows environment
+and again in Linux.
+
+This is because Docker doesn't let us run Windows and Linux on the same platform
+at the same time (Because it's not magic...).
+
+This probably isn't as big an issue as it looks since most projects are going to
+cater to one specific OS family.
 
 #### Worked Example
-Lets say you have two examples, `foo.pp` and `init.pp`.  In this case, the full range of files to create for acceptance testing would look like this:
+Lets say you have two examples, `foo.pp` and `init.pp`.  In this case, the full
+range of files to create for acceptance testing would look like this:
+
 ```
 mycoolmodule
 ├── examples
@@ -78,21 +143,34 @@ mycoolmodule
 PDQTest makes it easy to debug failed builds:
 
 ```shell
+# Centos
 pdqtest shell
+
+# Ubuntu
+pdqtest --image-name declarativesystems/pdqtest-ubuntu:2018-08-29-0 shell
 ```
 
-* Opens a shell inside the docker container that would be used to run tests
+* Opens a shell inside the default docker container that would be used to run 
+  tests
 * Your code is available at `/testcase`
+* Use `--image-name` to use a different image (Ubuntu)
+
 
 ```shell
 pdqtest --keep-container all
 ```
 * Runs all tests, report pass/fail status
 * Keeps the container Running
-* After testing, the container used to run tests will be left running and a message will be printed showing how to enter the container used for testing.  Your code is avaiable at `/testcase`
+* After testing, the container used to run tests will be left running and a 
+  message will be printed showing how to enter the container used for testing.
+  Your code is avaiable at `/testcase`
 * User is responsible for cleaning up the containers created in this mode
+* Shortcut: `make shell` or `.\make.ps1 shell`
 
 ### Docker privileged mode
-Sometimes you need to run in Docker privileged mode to enable tests to work - not ideal and if anyone else has a better idea please open a ticket with the details. When privileged mode is required, run `pdqtest --privileged` and you will have access.
+Sometimes you need to run in Docker privileged mode to enable tests to work - 
+not ideal and if anyone else has a better idea please open a ticket with the
+details. When privileged mode is required, run `pdqtest --privileged` and you
+will have access.
 
 WARNING: This grants the container access to the host

data/doc/caching.md

@@ -3,4 +3,8 @@ PDQTest will attempt to cache:
 * Puppet modules (via r10k) in `~/.r10k/cache`
 * The yum cache in `~/.pdqtest/cache/yum`
 
-Note that since the yum cache is writen to via a docker volume from the container your running tests in, the files in this directory will be root owned.  If you need to clear your cache for whatever reason, delete the `~/.pdqtest/cache` directory (you will likely need `sudo`) and PDQtest will recreate it next time it runs.
+Note that since the yum cache is writen to via a docker volume from the 
+container your running tests in, the files in this directory will be root owned.
+If you need to clear your cache for whatever reason, delete the 
+`~/.pdqtest/cache` directory (you will likely need `sudo`) and PDQtest will 
+recreate it next time it runs.

data/doc/development.md

@@ -1,15 +1,26 @@
 # Development
 
-PRs welcome :)  Please ensure suitable tests cover any new functionality and that all tests are passing before and after your development work.
+PRs welcome :)  Please ensure suitable tests cover any new functionality and 
+that all tests are passing before and after your development work.
 
 ## Support
-Interested in commercial support of PDQTest?  Please email sales@declarativesystems.com to discuss your needs.
+Interested in commercial support of PDQTest?  Please email 
+sales@declarativesystems.com to discuss your needs.
+
+## Debugging
+* run with `--verbosity debug`
+* Debug docker API calls: `export EXCON_DEBUG=debug` or `set EXCON_DEBUG=debug` 
+  then run `pdqtest` as normal
 
 ## Contributing
-Bug reports and pull requests are welcome on GitHub at https://github.com/declarativesystems/pdqtest.
+Bug reports and pull requests are welcome on GitHub at 
+https://github.com/declarativesystems/pdqtest.
 
 ### Running tests
-* PDQTest includes a comprehensive tests for core library functions.  Please ensure tests pass before and after any PRs
+* PDQTest includes a comprehensive tests for core library functions.  Please 
+  ensure tests pass before and after any PRs
 * Run all tests `bundle exec rake spec`
 * Run specific test file `bundle exec rspec ./spec/SPEC/FILE/TO/RUN.rb`
-* Run specific test case `bundle exec rspec ./spec/SPEC/FILE/TO/RUN.rb:99` (where 99 is the line number of the test)
+* Run specific test case `bundle exec rspec ./spec/SPEC/FILE/TO/RUN.rb:99` 
+  (where 99 is the line number of the test)
+* If your using RubyMine, you can just right-click -> debug

data/doc/emoji.md

@@ -1,22 +1,33 @@
 # Emoji
 
-Emoji are used within PDQTest to indicate progress and overall status at the request of PDQTest user.  Emoji are great because by visually scanning for a distinctive symbol, the user is able to understand the overall test status without having to scan through all of the debug messages.
+Emoji are used within PDQTest to indicate progress and overall status at the 
+request of PDQTest user.  Emoji are great because by visually scanning for a
+distinctive symbol, the user is able to understand the overall test status
+without having to scan through all of the debug messages.
 
-## What do the emoji mean?
+On windows, there is very limited support for Unicode in the terminal except in
+PowerShell ISE which is not compatible with PDK
+[PDK-1168](https://tickets.puppetlabs.com/browse/PDK-1168).
 
-### Progress
-`😬` Test passed
+On windows, we fallback to output emoticons instead of Emoji
 
-`💣` Test failed
+## What do the emoji mean?
 
-# Overall status
-`😎` All tests passed
+### Progress
 
-`💩` One or more tests failed
+| Symbol | Meaning | Platform                                 |
+| ---    | ---                             | ---              |
+| Progress: Test passed                    | `😬` | `:-)`      |
+| Progress: Test failed                    | `💣` | `●~*`      |
+| Overall Status: All tests passed         | `😎` | `=D`       |
+| Overall Status: One or more tests failed | `💩` | `><(((*>`  |
+| Slow operation                           | `🐌` | `(-_-)zzz` |
+| Platform issue/limitation                | - | `(-_-)`       |
 
 
 ## Disabling emoji
-In some cases it may be desirable to diable the emoji, in this case use the argument:
+In some cases it may be desirable to disable the emoji, in this case use the 
+argument:
 
 ```
 --disable-emoji

data/doc/enabling_testing.md

@@ -3,9 +3,21 @@ To add PDQTest to a new or existing puppet module, run the commands:
 
 ```shell
 pdqtest init
-bundle install
+pdk bundle install
 ```
 
-From the top level directory of your puppet module. This will install PDQTest into the `Gemfile` (for bundler), and generate an example set of acceptance tests.  The `bundle install` step will need development libraries installed if you haven't already obtained them.
+From the top level directory of your puppet module. This will install PDQTest 
+into the `Gemfile.project` (for PDK's bundler), and generate an example set of
+acceptance tests.  
 
-Note:  Your puppet module *must* have a valid `metatadata.json` file.  Create one before running `pdqtest init` if you don't already have one.  If your creating a puppet module from scratch, try `puppet module generate` to create a complete module skeleton that includes a valid version of this file.
+You **must** run `pdk bundle install` to install PDQTest into PDK's bundle and
+you **must not* run `bundle install` (ever!).
+
+For more info see (PDK-1172)[https://tickets.puppetlabs.com/browse/PDK-1172]
+
+PDK must already be present on the system for this to work.
+
+Note:  Your puppet module *must* have a valid `metatadata.json` file.  Create
+one before running `pdqtest init` if you don't already have one.  If your 
+creating a puppet module from scratch, try `pdk new module` to create a
+complete module skeleton that includes a valid version of this file.

data/doc/examples.md

@@ -1,10 +1,29 @@
 # Examples
 
 Here are some projects that use PDQTest:
-* https://github.com/geoffwilliams/puppet-motd
-* https://github.com/declarativesystems/download_and_do
-* https://github.com/GeoffWilliams/puppet-filemagic
-* https://github.com/declarativesystems/ssh
-* https://github.com/declarativesystems/puppet-chown_r/tree/master/spec/acceptance
 
-Do you use PDQTest on your own projects?  If you have a good public example let me know!
+## Linux projects
+* [realmd](https://github.com/GeoffWilliams/puppet-realmd)
+  Features mock realmd command
+* [sshkeys](https://github.com/GeoffWilliams/sshkeys)
+  Runs real SSH commands to test keys)
+* [sysctl](https://github.com/geoffwilliams/puppet-sysctl)
+  Features mock sysctl command that saves state between puppet runs
+* [motd](https://github.com/geoffwilliams/puppet-motd) 
+  A basic module with testing
+* [download_and_do](https://github.com/declarativesystems/download_and_do)
+  Test downloading files from local directory and running scripts
+* [filemagic](https://github.com/GeoffWilliams/puppet-filemagic) 
+  Complicated! and uses rspec tests on the ruby component of the module
+* [ssh](https://github.com/declarativesystems/ssh)
+  Fires up a real SSH server and tests status
+* [chown_r](https://github.com/declarativesystems/puppet-chown_r)
+  Checks permissions of files are correct after doing bulk operations with 
+  `chown -r` in an exec
+
+## Windows projects
+* Coming soon!
+
+
+Do you use PDQTest on your own projects?  If you have a good public example let
+me know!

data/doc/hiera.md

@@ -1,15 +1,25 @@
 # Hiera
-Under normal circumstances, only a `profile` module would be consuming Hiera data directly using the `hiera()` function, and its suggested by many that these too fall back to automatic data binding parameters rather then use the `hiera()` function directly.  In this case it makes more sense to use the excellent [Onceover](https://github.com/dylanratcliffe/onceover) tool to perform end-to-end testing of your Hiera data, puppet control repository and roles/profile modules.
+Under normal circumstances, only a `profile` module would be consuming Hiera 
+data directly using the `hiera()` function, and its suggested by many that these
+too fall back to automatic data binding parameters rather then use the `hiera()`
+function directly.  In this case it makes more sense to use the excellent 
+[Onceover](https://github.com/dylanratcliffe/onceover) tool to perform 
+end-to-end testing of your Hiera data, puppet control repository and 
+roles/profile modules.
 
 That said, there may be occasions where you need to mock hiera data:
-* You have implemented Roles and Profiles as a namespace inside a team module (for multi-tennanting)
-* You have a module that performs `hiera()` lookups directly
-* You intend to drive your module by adding data to hiera and including a class to make something happen
+* You have implemented Roles and Profiles as a namespace inside a team module 
+  (for multi-tennanting)
+* You have a module that performs `lookup()` lookups directly
+* You intend to drive your module by adding data to hiera and including a class
+  to make something happen
 * Your class fails to compile due to missing hiera data
-* You have a separate git repository for your `profile` module and want to be able to test it
+* You have a separate git repository for your `profile` module and want to be 
+  able to test it
 
 ## Alternative method
-In some cases where it may be easiest to directly inject strings in lieu of setting up a fake hiera:
+In some cases where it may be easiest to directly inject strings in lieu of 
+setting up a fake hiera:
 
 ### RSpec Tests
 ```ruby
@@ -29,15 +39,24 @@ class { "foo":
 }
 ```
 
-Note that you would need to duplicate your hard-coded mock data between the rspec tests and any acceptance tests.
+Note that you would need to duplicate your hard-coded mock data between the 
+rspec tests and any acceptance tests.
 
-In the more complex cases it may instead be desireable to mock the hiera data in order to enable Puppet's regular lookup systems to work.
+In the more complex cases it may instead be desireable to mock the hiera data in
+order to enable Puppet's regular lookup systems to work.
 
-## Mocking hiera
-PDQTest supports full mocking of Hiera for both RSpec and acceptance tests and support for this is enabled automatically when `pdqtest init` is run by versions of PDQTest >= 0.5.0.
+## Mocking Hiera (RSpec tests)
+PDQTest fully delegates RSpec tests to PDK, so see 
+[RSpec docs](https://rspec-puppet.com/documentation/configuration/) for how to
+do this.
+
+## Mocking hiera (Acceptance tests)
+PDQTest supports full mocking of Hiera acceptance tests and support for this is
+enabled automatically when `pdqtest init` is run.
 
 A basic one-level hierachy is created for you:
 * Hiera configuration file at `spec/fixtures/hiera.yaml`
 * Single hiera data file at `spec/fixtures/hieradata/test.yaml`
 
-Any required hiera data can be added to `test.yaml` and will immediately show up when lookups are made.
+Any required hiera data can be added to `test.yaml` and will immediately show up
+when lookups are made.

data/doc/installation.md

@@ -1,15 +1,66 @@
 # Installation
-PDQTest only runs on Linux/MAC systems.  If you are using Windows, the easiest way for you to run PDQTest is to install virtualisation software and then use [Vagrant](http://vagrantup.com/) to create a VM that shares a filesystem with your main Windows desktop.  This will allow you to edit your puppet code as you please and have it instantly show up inside of a Linux VM where you can run PDQTest and Docker.
+PDQTest runs on Linux/MAC and Windows systems, with the caveat that:
+* Windows acceptance tests can only be run on Windows
+* Linux acceptance tests can only run on Linux
+If you are using Windows and want to test Linux modules, the easiest way for you
+to run PDQTest is to install virtualisation software and then use 
+[Vagrant](http://vagrantup.com/) to create a VM that shares a filesystem with 
+your main Windows desktop.  This will allow you to edit your puppet code as you
+please and have it instantly show up inside of a Linux VM where you can run
+PDQTest and Docker.
 
-1. Install Ruby - you will need a fairly new version of Ruby as Puppet requires this.  [RVM](https://rvm.io/) or [RBENV](https://github.com/rbenv/rbenv) are easy ways of obtaining an up-to-date version.  Ruby 2.3 works prefectly.  You may need development libraries, eg `yum groupinstall 'Development Tools'` with these systems.  Once you have obtained a modern Ruby, follow any additional setup steps to activate the environment and then check it really worked by running `ruby --version` before proceeding.  Note that `pdqtest` should not be run as `root`.
+**Do NOT run PDQTest on a managed Puppet node, you may damage the agent**
+
+## Linux Instructions
+
+1. Install Ruby - you will need a fairly new version of Ruby as Puppet requires
+   this. On linux you will probably need development libraries, eg 
+   `yum groupinstall 'Development Tools'`. Once ruby is installed follow any 
+    additional setup steps to activate the environment and then check it really
+    worked by running `ruby --version` before proceeding.  Note that `pdqtest` 
+    should not be run as `root`. Easy ways to install an up-to-date Ruby:
+    * [RVM](https://rvm.io/)
+    * [RBENV](https://github.com/rbenv/rbenv)  
 2. Make sure `git` is installed - `yum install git`
-3. Install the gem version of puppet - `gem install puppet`
+3. Install the [PDK OS package](https://puppet.com/docs/pdk/1.x/pdk_install.html)
 4. Install PDQTest - `gem install pdqtest`
-5. Install bundler (the only sane way to manage Ruby dependencies) - `gem install bundler`
+5. Install bundler (the only sane way to manage Ruby dependencies) 
+   `gem install bundler`
 6. Install [Docker CE](www.docker.com)
-7. Start the `docker` daemon and make sure the user your running as is in the `docker` group.  You will need to log out and back in again after doing this
-8. Install the [PDQTest Docker image](https://hub.docker.com/r/geoffwilliams/pdqtest-centos/) by typing `pdqtest setup`
+7. Start the `docker` daemon and make sure the user your running as is in the
+   `docker` group.  You will need to log out and back in again after doing this
+8. Install the PDQTest docker images by typing `pdqtest setup`
+
+## Windows Instructions
+
+1. You will need Windows 10 (Windows 10 Enterprise, Professional, or Education)
+   and the system your running on must enable 
+   [VTx](https://en.wikipedia.org/wiki/X86_virtualization#Intel_virtualization_(VT-x))
+   which is needed for 
+   [Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-10)
+   running under 
+   [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/) 
+   which we use for testing:
+    * Laptops/Desktops - enable VTx in BIOS/UEFI
+    * VMs - You **must** run under VMWare and enable VTx in VM settings (as well
+      as enabling on the host)
+    * Make sure to allocate plenty of CPU and memory
+    * Enable Hyper-V (The Hyper-V role cannot be installed on Windows 10 Home)
+2. Install [Docker](http://docker.com/)
+    * [Docker for Windows](https://docs.docker.com/docker-for-windows/install) 
+      installed and 
+      [windows containers enabled](https://docs.docker.com/docker-for-windows/#switch-between-windows-and-linux-containers)
+    * [Docker API port enabled for localhost access](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon)
+    ```json
+    "hosts": ["tcp://127.0.0.1:2375"]
+    ```
+3. Install [Chocolatey](https://chocolatey.org/install)
+4. Install Ruby 2.4 (Ruby 2.5 doesn't work yet 
+   [PDK-1171](https://tickets.puppetlabs.com/browse/PDK-1171)): 
+   `choco install ruby --version 2.4.3.1`
+5. Install PDK: `choco install pdk`
+6. Install bundler `gem install bundler`
 
-You have now installed PDQTest.  Steps 6-8 are only required if running acceptance testing but are highly recommended.
+**Be sure to read the [Windows notes](windows.md) for guidance on how to run tests
+on Windows**
 
-Note:  Do *NOT* run PDQTest on a managed Puppet node, you may damage the agent.