Test on Windows, macOS and Linux from one machine

Testing on three operating systems does not require three desks. A single workstation with the right hypervisor can run clean, disposable copies of Windows and Linux — and, with the right hardware, macOS. The catch lies in the details: processor architecture, licensing and how quickly a machine can be reset to a known state.

Start with the one constraint you cannot work around

So the natural host is often a Mac with Apple silicon: it runs macOS, ARM Linux and Windows 11 on ARM guests. The reverse is not possible. If your product ships x86-64 Windows binaries, remember that Windows on ARM runs them through emulation, which is fine for functional tests but not for performance measurements.

On a Windows host

Windows Sandbox is the fastest way to answer "does my installer work on a clean machine?". It starts a lightweight copy of the host's Windows in seconds and throws everything away when closed. A .wsb file maps a folder and runs a command at startup:

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\builds\latest</HostFolder>
      <SandboxFolder>C:\build</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>C:\build\setup.exe /quiet</Command>
  </LogonCommand>
</Configuration>

For other Windows versions, Linux guests or anything that must persist between runs, use Hyper-V. Checkpoints make it ideal for destructive tests: restore, run, discard.

Checkpoint-VM -Name 'win10-qa' -SnapshotName 'clean'
# … run the test suite inside the VM …
Restore-VMCheckpoint -VMName 'win10-qa' -Name 'clean' -Confirm:$false

And for Linux command-line tools and services, WSL 2 runs real Linux distributions with almost no setup — enough for most server-side and CLI tests, though not a substitute for a full desktop Linux when you test a GUI.

On a Mac host

UTM is the approachable option: a graphical app that uses Apple's Virtualization framework for fast macOS and Linux guests, and QEMU when you need to emulate another architecture. It is free from its website and sold on the Mac App Store to fund development.

Tart targets automation. VMs are images stored in any OCI registry, so a CI job can pull a prepared macOS image, clone it, run the tests and delete the clone:

tart clone ghcr.io/cirruslabs/macos-sequoia-xcode:latest qa-run
tart run --no-graphics qa-run &
ssh admin@$(tart ip qa-run) 'cd project && ./run-tests.sh'
tart delete qa-run

Check Tart's licence terms before running it on a large fleet: it is free for personal use and small installations, with paid tiers beyond. For running Windows on a Mac, commercial hypervisors such as Parallels Desktop and VMware Fusion remain the most polished choices.

On a Linux host

QEMU with KVM gives near-native performance for Linux and Windows guests, and libvirt makes it scriptable. virt-install creates machines, virsh snapshots and reverts them, and virt-manager provides a GUI for the occasional manual session.

virsh snapshot-create-as fedora-qa clean --description 'fresh install'
# … run the tests …
virsh snapshot-revert fedora-qa clean

To cover many distributions cheaply, containers are often enough: a Debian, a Fedora and an openSUSE container will catch packaging and dependency problems in seconds. Keep full VMs for what containers do not share with the host — kernel modules, systemd boot behaviour, desktop sessions.

Cross-platform hypervisors

VirtualBox runs on all three systems on x86-64 and, combined with Vagrant, describes test machines in a versioned file that every team member can bring up the same way. On Apple silicon, its support for ARM guests is still young — UTM or Tart are the safer choices there.

Which one for which job

Habits that keep VM testing honest

• Always start from a snapshot. A test that passes on a machine where it passed yesterday proves less than one that passes on a clean install.
• Script the setup. A golden image built by hand cannot be rebuilt when a security update breaks it.
• Record the guest versions — OS build, runtime, browser — in the test report. "It worked on Windows" is not a version.
• Measure performance on bare metal. Virtualised timings are useful for trends, not for absolute numbers.

Local VMs shine during development and for exploratory testing. For every commit, hand the job to hosted runners with a GitHub Actions OS matrix.