Weblate 테스트 모음 및 지속적 통합

현재 코드의 대부분에 대해 테스트 모음이 존재합니다. 새 기능에 대한 테스트 케이스를 추가하여 커버리지를 높이고 작동하는지 확인하세요.

지속적 통합

Weblate는 코드 품질을 보장하기 위해 테스트 실행, 문서 빌드, 코드 린팅 및 기타 작업에 GitHub Actions 를 사용합니다.

Codecov 는 실행된 테스트에서 코드 커버리지 정보를 수집합니다.

다양한 측면을 확인하기 위한 여러 작업이 있음:

  • pytest 를 사용한 단위 및 기능 테스트.

  • Sphinx 를 사용한 문서 빌드 및 외부 링크.

  • ruff 및 pylint 를 사용한 코드 린팅 및 품질 보증.

  • CodeQL 를 사용한 코드 보안 스캔.

  • 시각적 변경 테스트는 Argos CI 를 활용합니다.

  • Code formatting using prek, a faster third-party reimplementation of the pre-commit framework.

  • 지원되는 모든 릴리스에서의 마이그레이션 테스트

  • 설정 확인 (생성된 배포 파일이 누락 없이 테스트 가능한지 확인)

CI 구성은 .github/workflows 디렉터리에 있습니다. ci 디렉터리에 저장된 헬퍼 스크립트를 많이 사용합니다. 스크립트를 수동으로 실행할 수도 있지만, 사용할 Django 설정 파일과 테스트 데이터베이스 연결을 정의하는 여러 환경 변수가 필요합니다. 예시 정의는 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

간단한 실행은 다음과 같음:

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

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.

테스트를 실행하기 전에 개발 의존성이 설치되어 있는지 확인하세요:

uv sync --all-extras --dev

pytest를 사용한 테스트

테스트를 실행하기 전에 일부 테스트가 정적 파일의 존재에 의존하므로 정적 파일을 수집해야 함:

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

pytest 를 사용하여 테스트 모음을 로컬에서 실행할 수 있습니다:

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.

개별 테스트 파일 실행:

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

힌트

테스트에 사용할 데이터베이스 (PostgreSQL) 서버가 필요합니다. 기본적으로 Django는 test_ 접두사로 테스트를 실행하기 위한 별도의 데이터베이스를 생성합니다. 따라서 설정이 weblate 를 사용하도록 구성된 경우 테스트는 test_weblate 데이터베이스를 사용합니다. 설정 지침은 Weblate 데이터베이스 설정 을 참조하세요.

weblate/settings_test.py 는 CI 환경에서도 사용됩니다 ( 지속적 통합 참조). 환경 변수를 사용하여 조정할 수 있음:

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

힌트

테스트는 개발자 Docker 컨테이너 내에서 실행할 수도 있습니다 ( Docker에서 Weblate를 로컬로 실행 참조).

더 보기

Django 테스트 실행 및 작성에 대한 자세한 정보는 Testing in 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.

Weblate 모듈 로컬 테스트

테스트는 pytest 를 사용하여 실행됩니다. 먼저 개발 의존성을 설치해야 합니다:

uv sync --all-extras --dev

그런 다음 저장소 체크아웃에서 테스트 모음을 실행할 수 있음:

uv run pytest

테스트 저장소

Weblate 테스트 모음의 많은 테스트가 테스트 저장소를 사용합니다. 테스트 모음 저장소는 https://github.com/WeblateOrg/test에서 관리됩니다. 그런 다음 scripts/pack-test-data.sh 스크립트를 사용하여 지원되는 각 버전 관리 시스템에 대한 저장소가 포함된 타르볼을 생성합니다. 이들은 Weblate 저장소에 weblate/trans/tests/data/test-base-repo.git.tar, weblate/trans/tests/data/test-base-repo.hg.tar 및 weblate/trans/tests/data/test-base-repo.svn.tar 로 저장됩니다.

https://github.com/WeblateOrg/test 저장소는 릴리스 시 태그가 지정되어 릴리스 태그를 사용하여 릴리스 시 사용된 테스트 데이터에 접근할 수 있습니다. 스크립트는 가능한 한 재현 가능한 타르볼을 만들려고 시도합니다.