Quality and testing

How every HF Panel release is tested before it is published: unit tests, screen checks, installer checks, automatic checks and a real install.

Every HF Panel release goes through the same tests before it is published. This page lists them, so you know what has been checked when you install a new version. For which release gets fixes, see Release policy.

Unit tests

Part	Tests
The server program (panels, HF Mail, HF Files, HF Studio, the API)	about 130 Go test files: account create, suspend and delete, backups and restores, SSL, email, DNS, billing webhooks, updates, the server agent's commands and routing in a cluster, sign-in, permissions of every role
HF Server (the desktop app)	its own Go tests
The interfaces (panels, HF Mail, HF Files, HF Studio, HF Server)	about 145 test files for the screens, run with Vitest, plus a type check of every interface and of the website
The documentation site	built from scratch; a link to a page that doesn't exist stops the build

The server tests run the panel against a real copy of its database schema, in dry run mode: every command for the server's agent is recorded instead of run, so a test checks exactly which commands an action sends, with which arguments. Passwords and private keys must only ever reach the agent as its input, never on its command line, and the tests check that too.

Screen checks

Every screen of the three panels has a check script. It signs in as each role that may open the screen, opens it and runs every action: success, each refusal, and another account's or a missing item. Each request runs twice from the same starting point, and the answers, the database afterwards and the agent's commands must be the same both times. A further sweep opens every screen as every role, and a browser test clicks through every screen twice and compares the two runs, including an accessibility check.

Installer and update checks

Without touching the machine, the installer check:

checks the syntax of every installer, agent and command-line script;
writes every web server file the installer and the agent make, for each layout (with and without email, IPv6 and the webmail address), and tests them with nginx -t;
converts a server from before 1.0.0 with the update's own functions and checks the result is the same as a fresh install, and that converting again changes nothing;
checks the update refuses an older version, keeps settings and data (it may only delete its own program copies), and changes nothing when it runs a second time;
checks the DNS records list, the mail server's names, the service files and the MongoDB databases service.

Automatic checks on every change

Every change to the source runs these automatically, and must pass before it is merged:

the Go code's formatting, go vet and the tests of the server program and HF Server, the server tests also with the race detector;
every interface's tests and type check, and the documentation site's build;
the check that the publisher's name and address are set in one place only, and the check of all 21 languages' translations;
shellcheck on the agent, the installer and the command-line tool;
the installer checks on Ubuntu 22.04 and 24.04.

A real install

Before a release, the package is built and installed for real on a throw-away Ubuntu 24.04 machine, with nothing in dry run. A script then drives the panel through the real Nginx: sign in, create an account, a domain, a mailbox, a database and a cron job, upload with HF Files, open HF Studio and webmail. It also makes a server from before 1.0.0, updates it while it keeps asking for panel pages (no page may fail during the update), runs the update a second time (nothing may change), checks the publisher's own mail, and uninstalls. Each step must end with "all good".

Email is tested end to end against real Postfix and Dovecot, the cluster with a real server joining and an account moving, account isolation against the real kernel, and two-factor passkeys in a browser.