Weblate testsuite och kontinuerlig integration¶

Testsuiter finns för större delen av den nuvarande koden. Öka täckningen genom att lägga till testfall för alla nya funktioner och verifiera att de fungerar.

Kontinuerlig integration¶

Weblate använder GitHub Actions för att köra tester, skapa dokumentation, kodgranska och utföra andra uppgifter för att säkerställa kodkvaliteten.

Codecov samlar in information om kodtäckning från de tester som har körts.

Det finns flera uppgifter för att verifiera olika aspekter:

Enhets- och funktionstester med hjälp av pytest.
Dokumentation och externa länkar med hjälp av Sphinx.
Kodgranskning och kvalitetssäkring med hjälp av ruff och pylint.
Kodsäkerhetsskanning med hjälp av CodeQL.
Visual changes testing is utilizing Argos CI.
Code formatting using prek, a faster third-party reimplementation of the pre-commit framework.
Migreringstestning från alla versioner som stöds
Verifiering av inställningar (säkerställer att genererade dist-filer inte saknar något och kan testas)

Konfigurationen för CI finns i katalogen .github/workflows. Den använder i stor utsträckning hjälpscript som finns lagrade i katalogen ci. Scripten kan också köras manuellt, men de kräver flera miljövariabler, främst för att definiera vilken Django-inställningsfil som ska användas och testa databasanslutningen. Ett exempel på en sådan definition finns i scripts/test-database.sh:

The Selenium screenshot tests in weblate/trans/tests/test_selenium.py serve two purposes. They generate images for visual change testing in CI, and the same images are converted into documentation screenshots by make -C docs update-screenshots. Keep screenshot fixtures close to real rendered pages so CI catches UI regressions. When a screenshot includes volatile runtime data, prefer deterministic server-side test inputs over post-render DOM changes.

# 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

Det enkla utförandet kan se ut så här:

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

Lokal testning av Weblate¶

Before running tests, please ensure development dependencies are installed:

uv sync --all-extras --dev

Testning med pytest¶

Innan du kör tester bör du samla in statiska filer, eftersom vissa tester är beroende av att de finns tillgängliga:

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

You can use pytest to run the test suite locally:

uv run pytest

Körning av en enskild testfil:

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

Råd

Du behöver en databas (PostgreSQL) server för att kunna utföra tester. Som standard skapar Django en separat databas för att köra tester med prefixet test_, så om dina inställningar är konfigurerade för att använda weblate, kommer testerna att använda databasen test_weblate. Se Databasinställningar för Weblate för installationsinstruktioner.

weblate/settings_test.py används även i CI-miljön (se Kontinuerlig integration) och kan justeras med hjälp av miljövariabler:

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

Råd

Testerna kan också köras inuti utvecklarens docker-container, se Kör Weblate lokalt i Docker.

Se även

Se Testing in Django för mer information om hur man kör och skriver tester för Django.

Lokal testning av Weblate-moduler¶

The tests are executed using pytest. First you need to install development dependencies:

uv sync --all-extras --dev

Du kan sedan köra testsuiten i arkivets utcheckning:

uv run pytest

Testarkiv¶

Många av testerna i Weblate-testpaketet använder testarkivet. Testpaketets arkiv underhålls på https://github.com/WeblateOrg/test. Skriptet scripts/pack-test-data.sh används sedan för att generera en tarball med ett arkiv för vart och ett av de versionkontrollsystem som stöds. Dessa lagras som weblate/trans/tests/data/test-base-repo.git.tar, weblate/trans/tests/data/test-base-repo.hg.tar och weblate/trans/tests/data/test-base-repo.svn.tar i Weblate-arkivet.

Arkivet https://github.com/WeblateOrg/test taggas vid release-tidpunkten, vilket säkerställer att releasetaggarna kan användas för att komma åt testdata som användes vid release-tidpunkten. Skriptet försöker skapa reproducerbara tarbollar i så stor utsträckning som möjligt.