Weblate tesztcsomag és folyamatos integráció¶
A jelenlegi kód nagy részéhez léteznek tesztcsomagok. Növelje a lefedettséget új funkciókhoz tartozó tesztesetek hozzáadásával, és ellenőrizze azok működését.
Folyamatos integráció¶
A Weblate a GitHub Actions szolgáltatást használja a tesztek futtatására, a dokumentáció összeállítására, a kódellenőrzésre és egyéb feladatokra a kódminőség biztosítása érdekében.
A Codecov összegyűjti a tesztekből származó kódfedettségi adatokat.
Több CI-feladat (job) fut, amelyek különböző szempontokat ellenőriznek:
Unit and functional tests using pytest.
Documentation build and external links using Sphinx.
Code security scanning using CodeQL.
Visual changes testing is utilizing Argos CI.
Code formatting using prek, a faster third-party reimplementation of the pre-commit framework.
Migrációs tesztelés minden támogatott verzióról
Beállítás ellenőrzése (Ellenőrzi, hogy a generált terjesztési fájlok (dist fájlok) teljesek-e, és tesztelhetők-e.)
A folyamatos integrációhoz (CI) tartozó konfiguráció a .github/workflows könyvtárban található. Ez nagymértékben támaszkodik a ci könyvtárban elhelyezett segédszkriptekre. A szkriptek manuálisan is futtathatók, de több környezeti változót igényelnek — főként a használandó Django beállításfájlt, valamint az adatbázis-kapcsolatot kell megadni. Erre példa található a scripts/test-database.sh fájlban:
# 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
Egyszerű futtatás például így nézhet ki:
source scripts/test-database.sh
./ci/run-migrate
./ci/run-test
./ci/run-docs
Weblate helyi tesztelése¶
Before running tests, please ensure development dependencies are installed:
uv sync --all-extras --dev
Tesztelés pytest használatával¶
A tesztek futtatása előtt szükséges az statikus fájlok összegyűjtése is, mivel egyes tesztek ezek meglétére támaszkodnak:
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
Egy adott tesztfájl futtatása:
uv run pytest weblate/utils/tests/test_search.py
Tipp
A tesztekhez szüksége lesz egy PostgreSQL adatbázis szerverre. Alapértelmezés szerint a Django egy külön adatbázist hoz létre a tesztekhez, amelynek neve test_ előtaggal kezdődik. Például ha a beállítások szerint az adatbázis neve weblate, akkor a tesztek a test_weblate nevű adatbázist fogják használni. Lásd a Adatbázis beállítása Weblate-hez részt a beállítás részleteihez.
A weblate/settings_test.py fájlt a CI környezet is használja (lásd: Folyamatos integráció), és környezeti változókon keresztül testreszabható:
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
Tipp
A tesztek a fejlesztői Docker-konténeren belül is futtathatók — lásd: Weblate futtatása helyileg Dockerben.
Lásd még
További információk Django tesztek írásáról és futtatásáról: Testing in Django.
Weblate-modulok helyi tesztelése¶
The tests are executed using pytest. First you need to install development dependencies:
uv sync --all-extras --dev
Ezután a letöltött tárolón belül lefuttathatja a tesztcsomagot:
uv run pytest
Testing repository¶
Many of the tests in the Weblate test suite use the test repository. The test
suite repository is maintained at https://github.com/WeblateOrg/test. The
script scripts/pack-test-data.sh is then used to generate a tarball
with a repository for each of the supported version control systems. These are
stored as weblate/trans/tests/data/test-base-repo.git.tar,
weblate/trans/tests/data/test-base-repo.hg.tar, and
weblate/trans/tests/data/test-base-repo.svn.tar in the Weblate
repository.
The https://github.com/WeblateOrg/test repository is tagged at the release time, which ensures that the release tags can be used to access test data used at the release time. The script tries to create reproducible tarballs as much as possible.