编写测试多语言网站的最佳方法是什么？

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 文件）。在语言环境文件中，定义元素 ID 和文本之间的映射。

2. 编写测试套件以将“locale”作为参数/环境变量。测试用例将根据 locale 参数引用适当的字典文件。测试用例将根据语言环境字典中定义的映射进行断言。

3. 以语言环境为参数运行测试套件。这帮助我避免了很多 if-else 条件和 switch 块！

它还有助于仅针对某个版本的特定语言运行测试。（并非每个版本都更新所有语言站点的场景）

Answer 2

首先，认识到测试每个特定 UI 元素的确切措辞是多余的。这意味着您在某处有一个执行实际本地化的本地化文件（例如 gettext PO 文件），并且您的测试文件中再次具有完全相同的信息，只是传播得更多。根据我的经验，文本的微小细节可能会偶尔发生变化，因此每次更新措辞时，也需要更新测试。本质上，您只是使测试与 PO 文件保持同步，以保证测试通过。这是大量多余的工作，没有太多好处。

\n\n

您这样做实际上是在测试什么？您的首要任务可能是测试您的本地化系统是否正常工作。如果您的 i18n/l10n 系统中存在错误，通常所有本地化都会被破坏。所以测试一切都是多余的。您可以简单地编写一个测试，对某些众所周知的字符串进行抽查，并检查它们是否已正确本地化为不同的语言。这应该足以捕获 i18n 系统中的故障。

\n\n

如果您使用类似 的占位符LOGIN_BUTTON_TEXT，您可能需要测试按钮文本是否不是“ LOGIN_BUTTON_TEXT”且不为空，以查看本地化是否正常工作，而无需确认每个按钮文本到底是什么。

\n\n

也许加载用于本地化文本的 PO 目录，并检查 UI 中显示的字符串是否是从 PO 文件翻译而来的字符串。同样，这会捕获 l10n 无法正常工作的错误，而无需将 PO 文件中的所有字符串复制到测试中。

\n\n

您可以进行功能测试，而无需关心确切的文本；通过按钮 ID 等寻址 UI 元素，检查输入是否通常处于“错误状态”，检查应该显示错误消息的元素是否通常存在且不为空。同样，也许会对某些特定的本地化字符串进行抽查，但不一定对所有.

\n\n

您应该与此分开对您的 PO 文件进行质量审核。像 gettext 这样的 i18n 系统在质量检查翻译方面拥有一个巨大的生态系统，您应该将它们用于此目的。E2E 测试不一定适合这样做。

\n\n

唯一一次对测试中应该出现在 UI 中的确切字符串进行硬编码是有意义的，那就是如果您使用TDD方法，并且您拥有 100% 像素完美的模型以及由您的设计预定义的 100% 准确的文本/ UX 团队认为这些模型 100% 按原样实现是 100% 最重要的。在这种情况下，测试就是规范，而实现则遵循测试。这还要求对于文本的任何更改，您都要经历模型 \xe2\x86\x92 规范 \xe2\x86\x92 测试 \xe2\x86\x92 实现周期。那么这是有道理的。
\n在任何其他情况下，您的测试将只是追逐实现，而这很少有用。

\n