Weblate testsuite en doorlopende integratie¶
Testsuites bestaan voor de meeste huidige code, verhogen dekking door toevoegen van testgevallen voor nieuwe functionaliteit, en verifiëren dat het werkt.
Doorlopende integratie¶
Weblate vertrouwt op GitHub Actions om testen uit te voeren, documentatie te bouwen, uitpluizen van code en ander taken om de kwaliteit van de code te verzekeren.
Codecov verzamelt de informatie over de bedekking van de code uit de testen die we uitvoeren.
Er zijn verscheidene taken om verschillende aspecten te verifiëren:
Eenheids- en functionele testen met pytest.
Documentatie voor bouwen en externe koppelingen met Sphinx.
Code beveiliging scannen met CodeQL.
Testen van visuele wijzigingen gebruikt Argos CI.
Code-opmaak gebruikt prek, een snellere herimplementatie van derde partij van het framewerk pre-commit.
Testen van migratie in alle ondersteunde uitgaven
Verificatie opstelling (zorgt ervoor dat gegenereerde bestanden voor de distributie niets missen en kunnen worden getest)
De configuratie voor de CI staat in de map .github/workflows. Het gebruikt in hoge mate hulpscripts die zijn opgeslagen in de map ci. De scripts kunnen ook handmatig worden uitgevoerd, maar zij vereisen verscheidene omgevingsvariabelen, die meestal het te gebruiken instellingenbestand voor Django definieert en de verbinding naar de database test. De voorbeelddefinitie daarvan staat in scripts/test-database.sh:
De schermafdrukken van testen van Selenium in weblate/trans/tests/test_selenium.py dienen twee doelen. Ze genereren afbeeldingen voor het testen van visuele wijzigingen in CI, en dezelfde afbeeldingen worden geconverteerd naar schermafdrukken voor documentatie met make -C docs update-screenshots. Houd exemplaren van schermafdrukken dicht bij de gerenderde pagina’s, zodat CI regressies in de gebruikersinterface vastlegt. Wanneer een schermafdruk veranderlijke gegevens uit runtime bevat, gebruik dan deterministische server-zijde testinvoer boven na-gerenderde wijzigingen in DOM.
URL’s voor opslagruimten van GitHub in deze schermafdrukken gebruiken lokaal herschrijven van Git-transport. Het gedeelde Git-inrichtingsarchief bevat de gewone testgegevens en een afzonderlijke, vastgezette demorevisie, dus ontdekken van de opslagruimte geeft alleen demo-inhoud weer. Maak het archief opnieuw met scripts/pack-test-data.sh; update zijn DEMO_REVISION bij het opzettelijk vernieuwen van de demogegevens. Runtime-testen halen geen opslagruimten van GitHub op of lossen hun hostnaam op. De vastgezette TEST_REVISION beheert de gewone gegevens van Git, Mercurial en Subversion onafhankelijk.
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
De eenvoudige uitvoering kan er uitzien als:
source scripts/test-database.sh
./ci/run-migrate
./ci/run-test
./ci/run-docs
Lokaal testen van Weblate¶
Voor een geïsoleerde omgeving met al geconfigureerde afhankelijkheden en testservices, gebruik de ontwikkelingscontainer. De CLI daarvan kan dezelfde pytest en lintopdrachten uitvoeren die hieronder zijn gedocumenteerd in elke Git-worktree.
Zorg ervoor, voor het uitvoeren van testen, dat de afhankelijkheden voor ontwikkeling zijn geïnstalleerd:
uv sync --all-extras --dev
Testen met pytest¶
Voorafgaande aan het testen zou u statische bestanden moeten verzamelen, omdat enkele testen erop vertrouwen dat die aanwezig zijn:
DJANGO_SETTINGS_MODULE=weblate.settings_test uv run ./manage.py collectstatic --noinput
U kunt pytest gebruiken om de testsuite lokaal uit te voeren:
uv run pytest
Op eigenschappen gebaseerde testen gebruiken het uitvoeren van hypothesis als deel van de normale pytestsuite. Ze controleren de veiligheid van uitvoer van Markdown, paden van leden van het back-uparchief, en parsen van SSH-URL’s met gebonden gemaakte invoer. Elke eigenschap voert maximaal 100 gemaakte bepalende voorbeelden uit, naast expliciete voorbeelden van regressie. Onverwachte uitzonderingen laten de test mislukken, en Hypothesis minimaliseert mislukkende invoer. Voeg geminimaliseerde invoer toe als expliciete voorbeelden voor regressie bij het repareren van een mislukking. Deadlines voor het vastleggen van tijd zijn uitgeschakeld om mislukkingen te vermijden die worden veroorzaakt door de lading van CI.
Uitvoeren van een individueel testbestand:
uv run pytest weblate/utils/tests/test_search.py
Hint
U zult een databaseserver (PostgreSQL) nodig hebben om te gebruiken voor de testen. Standaard maakt Django een afzonderlijke database, om testen mee uit te voeren, met het voorvoegsel test_, dus in het geval uw instellingen zijn geconfigureerd om weblate te gebruiken, zullen de testen de database test_weblate gebruiken. Bekijk Instellingen database voor Weblate voor instructies voor het instellen.
Het bestand weblate/settings_test.py wordt ook gebruikt in de omgeving van CI (bekijk Doorlopende integratie) en kan fijn worden afgestemd met omgevingsvariabelen:
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
Hint
De testen kunnen ook worden uitgevoerd binnen de Docker container voor ontwikkeling, bekijk Weblate lokaal in Docker uitvoeren.
Zie ook
Bekijk Testing in Django voor meer informatie over het uitvoeren en schrijven van testen voor Django.
Testen die herhaaldelijk hetzelfde onderdeel importeren, kunnen overnemen van ReusableComponentTestCase of ReusableViewTestCase in weblate/trans/tests/test_views.py. Deze basissen bouwen de initiële gebruiker, project, onderdeel en vertalingen eenmaal per klasse in setUpTestData(). Overschrijf create_component() om een opslaginrichting of een bestandsindeling te selecteren, net als met ComponentTestCase. Voor aanvullende instellingen, overschrijf de klassemethode build_fixture(cls, builder), roep aan super().build_fixture(builder), en gebruik de helpers voor de opslagruimte van de bouwer en instanties van het model.
Elke test herlaadt zijn modelinstanties en ontvangt een herstelde kopie van de werkende opslagruimten, opslagruimten upstream die worden gebruikt bij constructie en test-Git-configuratie. Databasewijzigingen worden teruggedraaid door Django. Cliëten, authenticatie en toepassingscaches worden per test geïnitialiseerd. Snapshots zijn tijdelijk en lokaal voor elke klasse en werker; extra onderdelen die zijn gemaakt binnen een test gebruiken nog steeds de normale onderdeelswerkplaatsen.
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.
Gebruik de bestaande basissen voor TransactionTestCase en opvolgende testen, of wanneer het construeren van onderdelen zelf moet worden uitgevoerd onder methodespecifiek overschrijven van instellingen. De herbruikbare basissen spelen niet opnieuw signalen af van het construeren van onderdelen of dienen terugroepen in voor elke test.
Lokaal testen van modules voor Weblate¶
De testen worden uitgevoerd met pytest. Eerst moet u afhankelijkheden voor ontwikkeling installeren:
uv sync --all-extras --dev
U kunt dan de testsuite uitvoeren in de checkout van de opslagruimte:
uv run pytest
Opslagruimten testen¶
Veel van de testen in de Weblate testsuite gebruiken de test-opslagplaats. De opslagruimte voor de testsuite wordt onderhouden op https://github.com/WeblateOrg/test. Het script scripts/pack-test-data.sh wordt dan gebruikt om een tarball te maken met een opslagruimte voor elk van de ondersteunde versiebeheersystemen. Deze worden opgeslagen als weblate/trans/tests/data/test-base-repo.git.tar, weblate/trans/tests/data/test-base-repo.hg.tar, en weblate/trans/tests/data/test-base-repo.svn.tar in de opslagruimte van Weblate.
De opslagruimte https://github.com/WeblateOrg/test wordt getagd bij de tijd bij uitgave, wat ervoor zorgt dat de uitgavetags kunnen worden gebruikt voor toegang tot testgegevens ten tijde van de uitgave. Het script probeert zoveel mogelijk nogmaals te produceren tarballs te maken.