Weblate-Testsuite und kontinuierliche Integration

Für den größten Teil des aktuellen Codes gibt es bereits Testsuiten. Erhöhen Sie die Erfassung, indem Sie Testfälle für neue Funktionen hinzufügen, und überprüfen Sie, ob diese funktionieren.

Kontinuierliche Integration

Weblate setzt auf GitHub Actions, um Tests auszuführen, Dokumentationen zu erstellen, Codeanalyse und andere Aufgaben zum Sicherstellen der Codequalität durchzuführen.

Codecov sammelt die Informationen zur Codeerfassung der durchgeführten Tests.

Es gibt mehrere Aufgaben, um verschiedene Aspekte zu überprüfen:

  • Einheiten- und Funktionstests mit pytest.

  • Erstellen der Dokumentation und externer Links mit Sphinx.

  • Codeanalyse und Qualitätssicherung mit ruff und pylint.

  • Code-Sicherheitsscan mit CodeQL.

  • Das Testen visueller Änderungen erfolgt mit Argos CI.

  • Code-Formatierung mit prek, einer schnelleren Drittanbieter-Reimplementierung des pre-commit-Frameworks.

  • Migrationstests von allen unterstützten Versionen

  • Überprüfung der Einrichtung (stellt sicher, dass die generierten Distributionsdateien keine Fehler enthalten und getestet werden können)

Die CI-Konfiguration befindet sich im Verzeichnis .github/workflows. Es verwendet hauptsächlich Hilfsskripte, die im Verzeichnis ci gespeichert sind. Die Skripte können auch manuell ausgeführt werden, benötigen aber mehrere Umgebungsvariablen, hauptsächlich für die Definition der zur verwendeten Django-Einstellungsdatei und dem Test der Datenbankverbindung. Die Beispiel-Definition dafür befindet sich in scripts/test-database.sh:

Die Selenium-Bildschirmfoto-Tests unter weblate/trans/tests/test_selenium.py dienen zwei Zwecken. Sie generieren Bilder für visuelle Änderungstests in der CI, und dieselben Bilder werden über make -C docs update-screenshots in Bildschirmfotos für die Dokumentation umgewandelt. Halten Sie die Bildschirmfotos möglichst nah an den tatsächlich gerenderten Seiten, damit die CI Regressionen in der Bedienoberfläche erkennt. Wenn ein Bildschirmfoto flüchtige Laufzeitdaten enthält, sollten deterministische serverseitige Testeingaben gegenüber DOM-Änderungen nach dem Rendern bevorzugt werden.

GitHub repository URLs in these screenshots use local Git transport rewrites. The shared Git fixture archive contains the ordinary test data and a separate, pinned demo revision, so repository discovery shows only demo content. Regenerate the archive with scripts/pack-test-data.sh; update its DEMO_REVISION when intentionally refreshing the demo data. Runtime tests do not fetch GitHub repositories or resolve their hostname. The TEST_REVISION pin controls the ordinary Git, Mercurial, and Subversion data independently.

Selenium tests that consume the standard demo can opt in with @reuse_demo_fixture from weblate/trans/tests/selenium_fixtures.py. Place it outside other method decorators. It restores committed database rows and the demo’s working repositories before the test body, so call create_component() before creating additional components as usual. Create users and other test-specific data inside the test body; restoration replaces the database. GitHub transports and browser state remain isolated per test. Keep creation and empty-state tests undecorated so they continue to exercise the browser forms and generate their screenshots.

# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later

# Simple way to configure test database from environment

# shellcheck shell=sh

# Database server configuration
export CI_DB_USER=weblate
export CI_DB_PASSWORD=weblate
export CI_DB_HOST=127.0.0.1

# Django settings module to use
export DJANGO_SETTINGS_MODULE=weblate.settings_test

Die einfache Ausführung kann wie folgt aussehen:

source scripts/test-database.sh
./ci/run-migrate
./ci/run-test
./ci/run-docs

OSS Scanner verification

The development Dockerfile shares its native dependencies and tooling between the development and scanner targets. VS Code, agent verification, and rundev.sh select development and retain mounted checkouts and separate Compose services. The final scanner target includes the checkout, locked Python dependencies, compiled assets, and local PostgreSQL and Valkey for verification without Internet access.

Build it from the repository root and run its offline smoke test:

docker build -f dev-docker/weblate-dev/Dockerfile -t weblate-oss-scanner .
docker run --rm --init --network none --user 0 --workdir /src --entrypoint bash \
    weblate-oss-scanner .oss-scanner/smoke

To run the complete backend suite, replace .oss-scanner/smoke with .oss-scanner/test. Append pytest selections or -n 0 for focused tests. No host mounts or external service containers are needed. The .github/workflows/rundev.yml workflow runs the focused smoke test on amd64, alongside the existing development-container checks.

The scanner uses Weblate-Bedrohungsmodell. The permissive test settings and local service authentication are test fixtures, not production deployment defaults.

Weblate lokal testen

Für eine isolierte Einsatzumgebung, in der Abhängigkeiten und Testdienste bereits konfiguriert sind, verwenden Sie den Entwicklungscontainer. Über dessen Befehlszeilenschnittstelle (CLI) lassen sich in jedem Git-Arbeitsverzeichnis dieselben pytest- und lint-Befehle ausführen, die im Folgenden beschrieben werden.

Bevor Sie Tests ausführen, stellen Sie bitte sicher, dass die Entwicklungsabhängigkeiten installiert sind:

uv sync --all-extras --dev

Mit pytest testen

Vor der Durchführung von Tests sollten Sie statische Dateien sammeln, da einige Tests auf deren Vorhandensein angewiesen sind:

DJANGO_SETTINGS_MODULE=weblate.settings_test uv run ./manage.py collectstatic --noinput

Sie können pytest verwenden, um die Testsuite lokal auszuführen:

uv run pytest

Property-based tests using hypothesis run as part of the normal pytest suite. They check Markdown output safety, backup archive member paths, and SSH URL parsing with bounded generated inputs. Each property runs up to 100 generated examples deterministically, alongside explicit regression examples. Unexpected exceptions fail the test, and Hypothesis minimizes failing inputs. Add minimized inputs as explicit regression examples when fixing a failure. Timing deadlines are disabled to avoid failures caused by CI load.

Ausführen einer einzelnen Testdatei:

uv run pytest weblate/utils/tests/test_search.py

Hinweis

Sie benötigen einen Datenbankserver (PostgreSQL), der für die Tests verwendet wird. Standardmäßig erstellt Django eine separate Datenbank, um Tests mit dem Präfix test_ auszuführen. Falls Ihre Einstellungen also so konfiguriert sind, dass weblate verwendet wird, werden die Tests die Datenbank test_weblate verwenden. Siehe Datenbankeinrichtung für Weblate für Anweisungen zur Einrichtung.

Die weblate/settings_test.py wird auch in der CI-Umgebung verwendet (siehe Kontinuierliche Integration) und kann mit Umgebungsvariablen angepasst werden:

export CI_DB_USER=weblate
export CI_DB_PASSWORD=weblate
export CI_DB_HOST=127.0.0.1
export CI_DB_PORT=60000
export DJANGO_SETTINGS_MODULE=weblate.settings_test

Hinweis

Die Tests können auch innerhalb eines Entwickler-Docker-Containers ausgeführt werden, siehe Weblate lokal in Docker ausführen.

Siehe auch

Siehe Testing in Django für weitere Informationen zum Ausführen und Schreiben von Tests für Django.

Tests that repeatedly import the same component can inherit from ReusableComponentTestCase or ReusableViewTestCase in weblate/trans/tests/test_views.py. These bases build the initial user, project, component, and translations once per class in setUpTestData(). Override create_component() to select a repository fixture or file format, as with ComponentTestCase. For additional shared setup, override the build_fixture(cls, builder) class method, call super().build_fixture(builder), and use the builder’s repository helpers and model instances.

Each test reloads its model instances and receives a restored copy of the working repositories, upstream repositories used during construction, and test Git configuration. Database changes are rolled back by Django. Clients, authentication, and application caches are initialized per test. Snapshots are temporary and local to each class and worker; extra components created within a test still use the normal component factories.

API tests inheriting APIBaseTest in weblate/api/tests.py use the same repository restoration. The API user and initial component, including its automatic glossary, are created once per class. Component construction callbacks run during this shared setup. API clients, credentials, and subclass setup such as screenshots and announcements are initialized per test.

Use the existing bases for TransactionTestCase and concurrency tests, or when component construction itself must run under a method-specific settings override. The reusable bases do not replay component construction signals or commit callbacks before each test.

Weblate-Module lokal testen

Die Tests werden mit pytest ausgeführt. Zuerst müssen Sie die Entwicklungsabhängigkeiten installieren:

uv sync --all-extras --dev

Sie können dann die Testsuite im Repository-Checkout ausführen:

uv run pytest

Test-Repository

Viele der Tests in der Weblate-Testsuite verwenden das Test-Repository. Das Repository für die Testsuite wird unter https://github.com/WeblateOrg/test verwaltet. Mit dem Skript scripts/pack-test-data.sh wird dann ein Tarball mit einem Repository für jede der unterstützten Versionsverwaltungen erzeugt. Diese werden als weblate/trans/tests/data/test-base-repo.git.tar, weblate/trans/tests/data/test-base-repo.hg.tar und weblate/trans/tests/data/test-base-repo.svn.tar im Weblate-Repository gespeichert.

Das Repository https://github.com/WeblateOrg/test wird zum Veröffentlichungszeitpunkt getaggt, wodurch sichergestellt wird, dass die Release-Tags für den Zugriff auf die zum Veröffentlichungszeitpunkt verwendeten Testdaten verwendet werden können. Das Skript versucht, so weit wie möglich reproduzierbare Tarballs zu erstellen.