Conjunto de testes e integração contínua do Weblate¶

Existem conjuntos de teste para a maior parte do código atual, aumente a cobertura adicionando casos de teste para qualquer nova funcionalidade e verifique se funciona.

Integração contínua¶

Weblate relies on GitHub Actions to run tests, build documentation, code linting, and other tasks to ensure code quality.

Codecov collects the code coverage information from the tests that were run.

Existem vários trabalhos para verificar diferentes aspectos:

Unit and functional tests using pytest.
Documentation build and external links using Sphinx.
Code linting and quality assurance using ruff and pylint.
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.
Testes de migração de todas as versões com suporte
Verificação de configuração (garante que os arquivos dist gerados não percam nada e possam ser testados)

A configuração do CI está no diretório .github/workflows. Ele usa muito scripts auxiliares armazenados no diretório ci. Os scripts também podem ser executados manualmente, mas eles requerem várias variáveis de ambiente, principalmente definindo o arquivo de configurações do Django para usar e conexão com o banco de dados de teste. A definição de exemplo disso está em 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.

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

A execução simples pode ser semelhante a:

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

Local testing of Weblate¶

For an isolated environment with dependencies and test services already configured, use the development container. Its CLI can run the same pytest and lint commands documented below in each Git worktree.

Before running tests, please ensure development dependencies are installed:

uv sync --all-extras --dev

Testando usando pytest¶

Antes de executar os testes, você deve coletar arquivos estáticos, pois alguns testes contam com a presença deles:

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

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.

Executando um arquivo de teste individual:

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

Dica

Você precisará de um servidor de banco de dados (PostgreSQL) a ser usado para os testes. Por padrão, o Django cria um banco de dados separado para executar testes com o prefixo test_, então no caso de suas configurações estarem configuradas para usar weblate, os testes usarão o banco de dados test_weblate. Consulte Configuração de banco de dados para o Weblate para instruções de configuração.

O weblate/settings_test.py é usado no ambiente CI também (consulte Integração contínua) e pode ser ajustado usando variáveis de ambiente:

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

Dica

Os testes também podem ser executados dentro de um contêiner Docker do desenvolvedor, consulte Executando Weblate localmente no Docker.

Ver também

Consulte Testando em Django para mais informações sobre a execução e escrita de testes para 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.

Local testing of Weblate modules¶

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

uv sync --all-extras --dev

Você pode então executar o testsuite no checkout do repositório:

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.