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 a adicionar casos de teste para qualquer nova funcionalidade e verifique se funciona.

Integração contínua¶

O Weblate depende do GitHub Actions para executar testes, compilar documentação, estilização de código, e outras tarefas para garantir qualidade de código.

Codecov recolhe informação de cobertura de código dos testes que foram executados.

Existem vários trabalhos para verificar diferentes aspectos:

Testes de unidade e funcionais usando pytest.
Criação de documentação e hiperligações externas utilizando Sphinx.
Formatação de código e garantia de qualidade usando ruff e pylint.
Análise de segurança de código usando CodeQL.
Testes de mudanças visuais usando Argos CI.
Formatação de código usando prek, uma re-implementação de terceiros mais rápida da estrutura pre-commit.
Testes de migração de todas as versões com suporte
Verificação de configuração (garante que os ficheiros dist gerados não percam nada e possam ser testados)

A configuração do CI está no diretório .github/workflows. Usa muitos scripts auxiliares armazenados no diretório ci. Os scripts também podem ser executados manualmente, mas requerem várias variáveis de ambiente, principalmente definindo o ficheiro de configurações do Django para usar e conexão com a base de dados de teste. A definição de exemplo disso está em scripts/test-database.sh:

Os testes de captura de ecrã do Selenium em weblate/trans/tests/test_selenium.py tem duas finalidades. Eles geram imagens para testes de mudanças visuais em CI, e as mesmas imagens são convertidas em capturas de ecrã de documentação por make -C docs update-screenshots. Mantenha os testes de captura de ecrã o mais próximos possível das páginas renderizadas reais, para que a CI detete regressões na interface do utilizador. Quando uma captura de ecrã inclui dados de execução voláteis, prefere entradas do servidor determinísticas do que mudanças de pós renderização DOM.

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

Testes locais do 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.

Antes de executar testes, certifique-se de que as dependências de desenvolvimento estão instaladas:

uv sync --all-extras --dev

Experimentar utilizando pytest¶

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

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

Pode usar pytest para executar o conjunto de testes localmente:

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 ficheiro de teste individual:

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

Dica

Precisará de um servidor de bases de dados (PostgreSQL) a ser usado para os testes. Por padrão, o Django cria uma base de dados separada para executar testes com o prefixo test_, então no caso que as suas configurações estarem configuradas para usar weblate, os testes usarão a base de dados test_weblate. Veja Configuração da base de dados para o Weblate para instruções de configuração.

O weblate/settings_test.py é usado no ambiente CI também (veja Integração contínua) e pode ser ajustado a usar 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 contentor Docker do programador, consulte Executando Weblate localmente no Docker.

Veja também

Veja Testing in 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.

Testar localmente os módulos do Weblate¶

Os testes são executados usando pytest. Primeiro precisa instalar dependências de desenvolvimento:

uv sync --all-extras --dev

Pode então executar o testsuite no checkout do repositório:

uv run pytest

A testar repositório¶

Muitos dos testes no conjunto de testes Weblate usam o repositório de teste. O repositório de conjuntos de testes é mantido em https://github.com/WeblateOrg/test. O script scripts/pack-test-data.sh é usado para gerar uma tarball com o repositório de cada sistema de versão de controlo suportado. Estes são armazenados como 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 no repositório Weblate.

O repositório https://github.com/WeblateOrg/test é etiquetado no momento do lançamento, o que garante que etiquetas de lançamento podem ser usadas para aceder a dados de teste usado no momento de lançamento. O script tenta criar tarballs reproduzíveis tanto quanto possível.