Pester

Finishing What We Started The Vagrant WSL2 provider had a test/integration_old/todos/ folder with unimplemented tests. Two big ones: test_provisioners.ps1 and test_docker.ps1. Both just had TODO comments saying what they should test. We’d already migrated the working tests to Pester 5.x format. The old homegrown PowerShell scripts worked fine - they just weren’t using a framework. Now we needed to implement these missing tests using the same Pester patterns. Provisioners: One Monolith, Five Tests The examples/provisioners/ directory had one massive Vagrantfile testing shell, file, ansible, chef, and salt provisioners all at once. To test them individually, we needed to split them up. ...

The Testing Problem The vagrant-wsl2-provider had integration tests. They worked. They ran actual Vagrant commands and verified WSL2 distributions got created properly. But they were all custom PowerShell scripts with manual error handling, inconsistent output, and no real test framework. Here’s what a typical test looked like: try { Write-Host "Test: Starting VM..." -ForegroundColor Yellow vagrant up if ($LASTEXITCODE -ne 0) { throw "vagrant up failed" } Write-Host "[PASS] VM started" -ForegroundColor Green } catch { Write-Host "[FAIL] Test failed" -ForegroundColor Red exit 1 } It worked, but it was painful to maintain. Each test file had its own error handling, cleanup logic, and output formatting. And when something failed, you got a wall of red text with no clear indication of which specific assertion broke. ...

The Question Nobody Asked Which WSL distributions from the Windows Store actually work with the Vagrant WSL2 Provider? I didn’t know. And I realized - that’s a problem. The provider uses wsl --install --distribution <name> to download and install distributions directly from the Windows Store. But there are 22 distributions available, and I’d only tested Ubuntu-24.04. Time to find out what works and what doesn’t. Building the Test The goal was simple: iterate through every distribution from wsl -l -o, try to create a Vagrant environment with it, and document what fails. ...

The Testing Journey So Far When I started this Vagrant WSL2 Provider project, I knew unit tests would be a waste of tokens. My requirements change daily. AI pair programming with Claude means rapid iteration, constant refactoring, and features that evolve as I discover what WSL2 can and can’t do. So I skipped unit tests entirely and went straight to integration tests. Simple PowerShell scripts that do the real thing: ...