Как лучше всего написать тест для тестирования многоязычного сайта?

Question

Я только что написал этот код для тестирования нашего процесса входа в систему для немецкой версии нашего сайта:

describe('login', () => {

    context('Language: DE', () =>{

        beforeEach(() => {
            ...
        })

        it('links to #/passwordforgotten', () => {
            ...
        })

        it('links to #/register', () => {
            ...
        })

        it('links to login further options', () => {
            ...
        })

        it('requires username', () => {
            ...
        })

        it('requires password', () => {
            ...
        })

        it('requires valid username and password', () => {
            ...
        })

        it('navigates to #/ on successful login', () => {
            ...
        }) 
    })
})

Наш сайт предлагается на девяти языках. Должен ли я повторить этот фрагмент кода для каждого языка:

describe('login', () => {

    context('Language: DE', () =>{
        ...
    })

    context('Language: EN', () =>{
        ...
    })

    context('Language: ES', () =>{
        ...
    })

    context('Language: IT', () =>{
        ...
    })

        ...
})

Или я должен реализовать логические структуры, когда дело доходит до проверки содержимого?

it('requires password', () => {

            cy.get('#UserName').type('username{enter}')
            const url = cy.hash()

            if(url.contains('de')) 
                cy.contains('Bitte geben Sie Ihr Passwort ein!')
            if(url.contains('en')) 
                cy.contains('Please enter your password!')
            if(url.contains('es')) 
                cy.contains('Por favor introduzca su contraseña')
            if(url.contains('it')) 
                cy.contains('Il nome utente o password non è corretto.')

            ...
        }

Что более эффективно? А что если этот набор тестов предназначен для регулярного запуска?

Answer 1

Я реализовал тестирование для многоязычного сайта, который поддерживает 40 языковых локалей, используя этот трюк:

1. Определите один словарь (JSON файл) для каждой локали. В файле локали определите соответствие между идентификатором элемента и текстом.

2. Напишите набор тестов, чтобы взять 'locale' в качестве переменной параметра / среды. Контрольные примеры будут ссылаться на соответствующий файл словаря на основе параметра locale. Тестовый случай выполнит утверждения на основе отображений, определенных в словаре языковых стандартов.

3. Запуск набора тестов с языковым стандартом в качестве параметра. Это помогло мне избежать многих условий if-else и переключать блоки!

Это также помогло запустить тесты только для определенных c языков для выпуска. (Сценарий, в котором не все языковые сайты обновлялись для каждого выпуска)

Answer 2

Прежде всего, признайте избыточность тестирования точной формулировки каждого конкретного элемента пользовательского интерфейса. Это означает, что у вас есть файл локализации, который выполняет фактическую локализацию (например, файл PO gettext), и у вас снова есть та же самая информация в ваших тестовых файлах, просто распространяйте больше. По моему опыту, небольшие детали текста могут меняться время от времени, поэтому каждый раз, когда вы обновляете формулировку, вам также необходимо обновлять тесты. По сути, вы просто синхронизируете свои тесты c с PO-файлом, чтобы тесты проходили успешно. Это много лишней работы без большого роста.

Что вы на самом деле тестируете, делая это? Ваш главный приоритет, вероятно, состоит в том, чтобы проверить, работает ли ваша система l10n. Если в вашей системе i18n / l10n есть ошибка, как правило, все локализации будут нарушены. Так что излишне проверять все. Вы можете просто написать один тест, который выполняет выборочные проверки некоторых хорошо известных строк и проверяет, правильно ли они локализованы на разных языках. Этого должно быть достаточно для обнаружения сбоев в системе i18n как таковой.

Если вы используете заполнители, такие как LOGIN_BUTTON_TEXT, вы можете проверить, являются ли тексты ваших кнопок не"LOGIN_BUTTON_TEXT "и не пусто, чтобы увидеть, работают ли локализации вообще, без необходимости подтверждать, какой текст каждой кнопки точно .

Возможно, загрузите каталог ПО, который вы используете локализовать ваш текст и убедиться, что строка, отображаемая в пользовательском интерфейсе, переведена из PO-файла. Опять же, это выявляет ошибки, когда l10n почему-то не работает, без необходимости копировать все строки из PO-файла в ваши тесты.

Вы можете выполнять свои функциональные тесты, не заботясь о точных текстах; Адресация элементов пользовательского интерфейса с помощью идентификаторов кнопок и т. д., проверьте, находятся ли входы, как правило, «в состоянии ошибки» или нет, проверьте, существуют ли элементы, которые должны отображать сообщения об ошибках, в целом и не являются ли они пустыми. Опять же, возможно, сделайте выборочные проверки для определенных указанных c локализованных строк, но необязательно для всех .

Вы должны провести качественный аудит ваших PO-файлов отдельно из этого. Системы i18n, такие как gettext, имеют огромную экосистему вокруг проверок качества переводов, и вы должны использовать их для этой цели. Тесты E2E не обязательно являются подходящим местом для этого.

Единственный раз, когда имеет смысл жестко закодировать точную строку, которая должна появляться в пользовательском интерфейсе в ваших тестах, это если вы работаете с TDD подход, и у вас есть 100% пиксельные макеты с 100% точным текстом, предопределенные вашей командой дизайнеров / UX, и на 100% важно, чтобы эти макеты были реализованы на 100% как есть. В этом случае тесты - это spe c, а реализация следует за тестами. Это также требует, чтобы при любом изменении текста вы go выполняли макет → spe c → тест → цикл реализации. Тогда это имеет смысл.
В любом другом случае ваши тесты будут просто отслеживать реализацию, а это редко полезно.