வலைபெயர்ப்பு சோதனைகள் மற்றும் தொடர்ச்சியான ஒருங்கிணைப்பு

தற்போதைய குறியீட்டின் பெரும்பகுதிக்கு டெச்சூட்கள் உள்ளன, எந்தவொரு புதிய செயல்பாட்டிற்கும் சோதனை பெட்டிகளைச் சேர்ப்பதன் மூலம் கவரேசை அதிகரிக்கின்றன, மேலும் அது செயல்படுகிறதா என்பதை சரிபார்க்கவும்.

தொடர்ச்சியான ஒருங்கிணைப்பு

குறியீடு தரத்தை உறுதிப்படுத்த சோதனைகளை இயக்க, ஆவணங்கள், குறியீடு லிண்டிங் மற்றும் பிற பணிகளை உருவாக்க வலைபெயர்ப்பு கிட்அப் செயல்கள் ஐ நம்பியுள்ளது.

கோடெகோவ் இயக்கப்பட்ட சோதனைகளிலிருந்து குறியீடு கவரேச் தகவல்களை சேகரிக்கிறது.

வெவ்வேறு அம்சங்களை சரிபார்க்க பல வேலைகள் உள்ளன:

  • 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.

  • Code formatting using pre-commit.

  • ஆதரிக்கப்படும் அனைத்து வெளியீடுகளிலிருந்தும் இடம்பெயர்வு சோதனை

  • அமைவு சரிபார்ப்பு (உருவாக்கப்பட்ட மாவட்ட கோப்புகள் எதையும் இழக்காமல் இருப்பதை உறுதி செய்கிறது மற்றும் சோதிக்கப்படலாம்)

The configuration for the CI is in .github/workflows directory. It heavily uses helper scripts stored in ci directory. The scripts can be also executed manually, but they require several environment variables, mostly defining Django settings file to use and test database connection. The example definition of that is in 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 backend to use postgresql / mysql / mariadb
export CI_DATABASE="${1:-postgresql}"

# 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

வெப்லேட்டின் உள்ளக சோதனை

Before running test, please ensure test dependencies are installed. This can be done by pip install -e .[test].

Pytest ஐப் பயன்படுத்தி சோதனை

சோதனைகளை இயக்குவதற்கு முன் நீங்கள் நிலையான கோப்புகளை சேகரிக்க வேண்டும், ஏனெனில் சில சோதனைகள் அவை இருப்பதை நம்பியுள்ளன:

DJANGO_SETTINGS_MODULE=weblate.settings_test ./manage.py collectstatic

உள்நாட்டில் ஒரு டெச்ட்சூட்டை இயக்க நீங்கள் பைடெச்ட் ஐப் பயன்படுத்தலாம்:

pytest weblate

ஒரு தனிப்பட்ட சோதனை கோப்பை இயக்குதல்:

pytest weblate/utils/tests/test_search.py

Hint

You will need a database (PostgreSQL) server to be used for tests. By default Django creates separate database to run tests with test_ prefix, so in case your settings is configured to use weblate, the tests will use test_weblate database. See வலைபெயர்ப்புடுக்கான தரவுத்தள அமைப்பு for setup instructions.

The weblate/settings_test.py is used in CI environment as well (see தொடர்ச்சியான ஒருங்கிணைப்பு) and can be tuned using environment variables:

export CI_DATABASE=postgresql
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

The tests can also be executed inside developer docker container, see டாக்கரில் உள்நாட்டில் வலைபெயர்ப்பு இயங்குகிறது.

See also

See Testing in Django for more info on running and writing tests for Django.

வலைபெயர்ப்பு தொகுதிகளின் உள்ளக சோதனை

The tests are executed using py.test. First you need to install test requirements:

uv pip install -e '.[dev]'

களஞ்சிய செக்அவுட்டில் சோதனைச்சூட்டை நீங்கள் செயல்படுத்தலாம்:

py.test

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.