Introduction

This page outlines the tests we do or should run on Windows. Other pages of interest:

• OpenVPN 2.4 Windows tests

Usage patterns to test

GUI-based usage (OpenVPN-GUI)

Right now OpenVPN-GUI testing has not been automated, and all tests are manual:

• Without Interactive Service, with admin privileges
• With Interactive Service, without admin privileges
• With Interactive Service, with admin privileges

That said, ​OpenVPN-GUI communicates with OpenVPN using the management interface, as do all the more recent GUIs. Thus management interface tests (below) will eventually help verify correct operation of OpenVPN-GUI. All the basic functions of OpenVPN-GUI should be tested, but how would these tests be automated? Would it require an automation API in OpenVPN-GUI itself?

OpenVPN as a service (openvpnserv2)

All the basic functionality of ​openvpnserv2 should be tested. Right now the tests have to be run manually:

• Ensuring that the service can be enabled / disabled / started / stopped on all platforms
• Restarting a connection that goes down
• What happens with broken configuration files? What is the proper behavior?
• What happens with conflicting configuration files? What is the proper behavior?

Direct use from the command-line

Basic usage from the command-line (cmd.exe) should be tested. This is covered by cron2's run.bat/run2.bat script. At minimum we should test these:

• Connect and disconnect to a VPN as admin (should work)
• Connect to a VPN as unprivileged user (should fail cleanly)

Windows-specific command-line tools

netsh

Ensure that the netsh calls that OpenVPN makes have the desired effect. There are no automated tests for this yet.

Windows-specific options

Ensure that various Windows-specific options behave as excepted

ip-win32

• dynamic (= DHCP)
• ipapi (= windows API system calls)
• netsh (= netsh.exe calls)
• maybe even "adaptive" (= try ipapi, fall back to dynamic)

My minimal run.bat test has cases for that, and it seems --ip-win32 netsh is already unreliable today, even before d12fk's do_ifconfig_after_tun patch.

Management interface

Ensure that management interface commands work as expected, with particular focus on the commands and sequences that a GUI typically uses. These tests should automated immediately. Questions:

• How do we automate the tests?
• What are the commands and sequences we should test?

Right now there are no tests, not even ones that are run manually.

Basic connectivity testing

Extend t_client.sh tests to Windows also. Right now: barebones run.bat+run2.bat

Infrastructure needed for the tests

• t_client server side
• what about testing "clients on other systems, server on windows"?