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 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:
# 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¶
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
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.
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.