Skip to content
A testing setup related to how the Chocolatey Package Verifier runs testing. Used for manual testing or prior to submission
Branch: master
Clone or download
Pull request Compare This branch is 48 commits ahead, 9 commits behind chocolatey-community:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
shell add uninstaller via param Oct 10, 2019

Chocolatey Testing Environment

A testing environment setup similar to the package-verifier for testing packages.

When creating packages, please review


You need a computer with:

  • a 64-bit processor and OS
  • Intel VT-x enabled (usually not an issue if your computer is newer than 2011). This is necessary because we are using 64bit VMs.
  • Hyper-V may need to be disabled for Virtualbox to work properly if your computer is a Windows box. NOTE: This may actually not be required. If required, run bcdedit /set hypervisorlaunchtype off then reboot.
  • At least 10GB of free space.


To install prerequisites:

# Only if you use VirtualBox
choco install virtualbox 

# Only if you use Hyper-V
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

choco install vagrant
vagrant plugin install sahara

Now run one of the:

vagrant up                       # uses vbox by default
vagrant up --provider hyperv     # uses hyper-v


  • VirtualBox 4.3.28+ [ choco install virtualbox ]
  • Vagrant 1.8.1+ [ choco install vagrant ] Linked clones is the huge reason here. You can technically use any version of Vagrant 1.3.5+, but you will get the best performance with 1.8.x.
    • Vagrant Sahara plugin [vagrant plugin install sahara]

Running Verification Manually

Preparing the Testing Environment

  1. Ensure setup above is good on your machine.
  2. Fork and Clone this repository
  3. Open a command line (PowerShell.exe/cmd.exe on Windows, bash everywhere else) and navigate to the root folder of the repository. You know you are in the right place when you do a dir or ls and Vagrantfile is in your path.
  • No idea if bash on Windows (through Git/CygWin) is supported. If you run into issues, it is better to just use PowerShell.exe or cmd.exe. Please do not file issues stating it doesn't work.
  1. Run vagrant up to prepare the machine for testing.
  • Note due to the way that vagrant works, the first time that you run this command, the vagrant box named ferventcoder/win2012r2-x64-nocm needs to be downloaded from the Atlas website. This will take quite a while, and should only be attempted on a reasonably fast connection, that doesn't have any download limit restrictions. Once it has downloaded it will import the box and apply the scripts and configurations to the box as listed inside the Vagrantfile. You can find the downloaded box in the ~/.vagrant.d or c:\users\username\.vagrant.d folder.
  1. Now the box is ready for you to start testing against.
  2. Run the following command: vagrant sandbox on. This takes a snapshot of the VM using the vagrant plugin that was installed earlier. This means that after testing packages, the VM can be returned to this known "good" state.

Testing a Package

Testing can be manual or fully automatic.

Manual testing

For testing a package, you have two avenues. For a locally built package, you can drop the package into the packages folder in the root of the cloned repository - it is shared with the box as C:\packages, so you can run a command on the box or with the inline provisioner (recommended as it is a closer match to the verifier) using --source c:\packages as an argument for installation. If you are trying to reproduce/investigate a problem with a package already up on the website, you can use --version number with your install arguments and that will let you install a package that is not listed (in most cases not yet approved).

  1. Search the User.ps1 script for # THIS IS WHAT YOU CHANGE. Uncomment and edit the line which best meets the current situation that you are testing.
  2. Run vagrant provision.
  3. Watch the output and go to the box for further inspection if necessary.

Automatic testing

You can just copy your packages to the packages directory and automatic install will run during provision.
Use environment variable $Env:PACKAGES to pass names and versions of community packages to install:

$Env:PACKAGES = 'copyq dbeaver:2.7.1'; vagrant up --provision

For best experience use AU PowerShell module and its function Test-Package that can test install and/or uninstall both locally and using vagrant.

The following example will run both install and uninstall for the package 'yed' and pass it custom parameter.

C:\au-packages\yed> $au_Vagrant = 'c:\chocolatey\chocolatey-test-environment' #you can also add this to your profile
C:\au-packages\yed> Test-Package -Parameters '/Shortcut'

Package info
  Path:         C:\au-packages\yed\yed.
  Name:         yed
  Parameters:   /Shortcut
  Vagrant:      c:\chocolatey\chocolatey-test-environment

Testing package using vagrant
Removing existing vagrant packages


==> default: Running provisioner: shell...
    default: Running: shell/TestPackages.ps1 as c:\tmp\vagrant-shell.ps1
==> default: ============================================================
==> default: ============================================================
==> default:
==> default: ------------------------------------------------------------
==> default: PACKAGE: yed:
==> default:
==> default: OPTIONS: c:\packages\yed.
==> default:
==> default: Name                           Value
==> default: ----                           -----
==> default: Install                        True
==> default: Uninstall                      True
==> default: Parameters                     /Shortcut
==> default: ------------------------------------------------------------
==> default:
==> default: TESTING INSTALL FOR yed:
==> default: Choco cmd: choco install -fy yed --allow-downgrade --version --source "'c:\packages;'"  --params '/Shortcut'
==> default: Chocolatey v0.10.3
==> default: Installing the following packages:
==> default: yed

Make Changes and Retest

When you need to investigate making changes and rerunning the tests, remember that we took a snapshot of the vagrant machine (the virtual machine), so we can rollback to the earlier state each time and move forward with testing changes without the possibility of lingering artifacts. This is why we are using the sahara vagrant plugin, it allows us to take a snapshot and then revert the virtual machine back to the previous state.

When you are ready to reset to the state just before installing:

  1. Run vagrant sandbox rollback
  2. Follow the steps in testing a package (previous section).

Tearing Down the Testing Environment

NOTE: At any time you can:

  • stop the box with vagrant suspend, vagrant halt
  • delete the box with vagrant destroy

For more information on vagrant commands, see the Vagrant Docs


An authorization error occurred while connecting to WinRM [vBox]

Install latest VBox Guest Additions

A Vagrant environment or target machine is required to run this command

Run vagrant init to create a new Vagrant environment. Or, get an ID of a target machine from vagrant global-status to run this command on. A final option is to change to a directory with a Vagrantfile and to try again." - please ensure you are on the correct working directory (where this ReadMe and Vagrantfile is) of this repo and try again.

Machine can't be created due to virtual switch problem [hyper-v]

Create Hyper-v switch manually with

# Find out adapter name
# Get-NetAdapter
New-VMSwitch -Name DefaultSwitch -NetAdapterName Ethernet -AllowManagementOS $true  
You can’t perform that action at this time.