कमजोर परीक्षण लिखे बिना अनुवादों का परीक्षण कैसे करें

अधिकांश i18n टेस्ट सुइट दो में से किसी एक तरीके से विफल होते हैं। या तो वे सटीक शब्दों पर असर्शन लगाते हैं, जिससे हर छोटे बदलाव पर पचास टेस्ट टूट जाते हैं और टीम उन्हें हटा देती है। या फिर वे सब कुछ केवल डिफ़ॉल्ट लोकेल में रेंडर करते हैं, जिससे अन्य सत्रह भाषाओं के बारे में कुछ भी सिद्ध नहीं होता। दोनों का परिणाम एक ही होता है, एक ऐसा सुइट जिस पर कोई भरोसा नहीं करता।

विषय सूची

पैटर्न लाइब्रेरी-स्वतंत्र हैं

नीचे दिया गया प्रत्येक पैटर्न किसी भी i18n स्टैक पर काम करता है। प्रोवाइडर को I18nextProvider, NextIntlClientProvider या IntlProvider से बदलें और परीक्षण बिल्कुल समान रहेंगे, क्योंकि वे किसी लाइब्रेरी API के बजाय रेंडर किए गए आउटपुट का परीक्षण करते हैं।

कवरेज टूलिंग भी आसानी से पोर्ट हो जाती है: आपके मौजूदा कैटलॉग को लक्षित करने वाले Sync JSON प्लगइन, या आपके वर्तमान इम्पोर्ट को एलियास करने वाले कम्पैट एडॉप्टर के साथ, कवरेज असर्शन सीधे आपके मौजूदा JSON पर चलता है।

तय करें कि आप वास्तव में क्या परीक्षण कर रहे हैं

अनुवाद की गुणवत्ता कोड टेस्ट से जांची जाने वाली चीज़ नहीं है। कोई भी असर्शन यह नहीं बता सकता कि जर्मन स्वाभाविक लग रही है या नहीं, और ऐसा करने की कोशिश करने से आपका टेस्ट सुइट हार्डकोडेड स्ट्रिंग्स से भर जाता है।

वास्तव में क्या परीक्षण करने योग्य है, वह यांत्रिक है:

कवरेज की जांच एक डेटा-संचालित परीक्षण में होनी चाहिए, आपके कंपोनेंट परीक्षणों में नहीं। इसे अनुपस्थित अनुवादों का पता लगाना में विस्तार से बताया गया है; यह पोस्ट बाकी चीज़ों के बारे में है।

प्रोवाइडर के तहत रेंडर करें और रोल (Role) पर जोर दें

मुख्य पैटर्न कंपोनेंट को लोकेल प्रोवाइडर के अंदर माउंट करना और टेक्स्ट के बजाय रोल या टेस्ट आईडी द्वारा क्वेरी करना है।

import { render, screen } from "@testing-library/react";
import { IntlayerProvider } from "react-intlayer/client";
import { CartSummary } from "./CartSummary";

test("फ्रेंच में सारांश शीर्षक रेंडर करता है", () => {
  render(
    <IntlayerProvider locale="fr-FR">
      <CartSummary />
    </IntlayerProvider>
  );

  expect(screen.getByRole("heading")).toBeInTheDocument();
});

getByRole("heading") से क्वेरी करना टेक्स्ट में बदलाव होने पर भी बरकरार रहता है। getByText("Récapitulatif") तुरंत टूट जाता है। सटीक टेक्स्ट का उपयोग केवल तभी करें जब स्ट्रिंग ही परीक्षण का विषय हो, जो बहुत दुर्लभ है।

aria-label जैसे एट्रिब्यूट के लिए आपको रेंडर करने योग्य नोड के बजाय रॉ स्ट्रिंग की आवश्यकता होती है। React में, useIntlayer प्रविष्टियां इसके लिए .value फ़ील्ड प्रदान करती हैं।

सभी लोकेल में परीक्षणों को पैरामीटराइज़ करें

प्रत्येक भाषा के लिए अलग टेस्ट लिखने की तुलना में सभी लोकेल में चलने वाला एक टेस्ट लॉजिक कहीं अधिक मूल्यवान है।

import { getHTMLTextDir } from "intlayer";
import { render } from "@testing-library/react";
import { IntlayerProvider } from "react-intlayer/client";

describe.each(["en", "fr", "ja", "ar"])("locale %s", (locale) => {
  it("कुंजी (key) पर वापस जाए बिना रेंडर होता है", () => {
    const { container } = render(
      <IntlayerProvider locale={locale}>
        <CartSummary />
      </IntlayerProvider>
    );

    // यदि कुंजी रेंडर होती है तो लुकअप विफल रहा है।
    expect(container.textContent).not.toMatch(/^[a-z]+(\.[a-z]+)+$/);
  });

  it("सही टेक्स्ट दिशा सेट करता है", () => {
    expect(getHTMLTextDir(locale)).toBe(locale === "ar" ? "rtl" : "ltr");
  });
});

पहला असर्शन एक सस्ता सामान्य लाभ है: यदि कोई लुकअप विफल हो जाता है और आपकी लाइब्रेरी कुंजी प्रदर्शित करती है, तो DOM में cart.summary.title जैसा कुछ दिखाई देगा। यह किसी एक स्ट्रिंग का नाम लिए बिना बग के पूरे वर्ग को पकड़ लेता है।

स्यूडोलॉकालाइज़ेशन वह ढूंढता है जो कैटलॉग नहीं देख सकते

एक नकली लोकेल जोड़ें जो प्रत्येक स्ट्रिंग को बदल दे, उदाहरण के लिए Checkout को [!!! Çĥéçķöũţ !!!] में बदलना। फिर उस लोकेल में पेज को रेंडर करें।

जो कुछ भी अभी भी सामान्य अंग्रेज़ी में दिखाई दे रहा है वह कोड में हार्डकोड किया गया है। कैटलॉग-आधारित कोई भी ऑडिट इसे नहीं पकड़ सकता, क्योंकि टूल्स की नज़र में वह स्ट्रिंग मौजूद ही नहीं है। कोष्ठक दूसरा काम करते हैं: वे टेक्स्ट को लगभग 30 प्रतिशत बढ़ा देते हैं, जिससे लेआउट टूटने की समस्या पहले ही सामने आ जाती है।

इसे यूनिट टेस्ट के बजाय विजुअल या एंड-टू-एंड पास के रूप में चलाना अधिक फायदेमंद है, क्योंकि यह विफलता देखने योग्य होती है।

बहुवचनों को भाषा के अनुसार नहीं, बल्कि श्रेणी के अनुसार टेस्ट करें

बहुवचन के बग इसलिए छिपे रहते हैं क्योंकि अंग्रेज़ी में केवल दो रूप होते हैं और अधिकांश डेवलपर्स केवल उन्हीं का परीक्षण करते हैं। पोलिश में चार रूप हैं, अरबी में छह।

// अरबी zero, one, two, few, many, other को कवर करती है।
describe.each([0, 1, 2, 3, 11, 100])("count %i", (count) => {
  it("अरबी में गैर-रिक्त स्ट्रिंग उत्पन्न करता है", () => {
    expect(formatItems(count, "ar")).not.toBe("");
  });
});

हर जगह केवल 1 और 2 का परीक्षण करने के बजाय अपनी सबसे जटिल भाषा के लिए प्रत्येक CLDR श्रेणी को छूने वाले आंकड़े चुनें। Intl.PluralRules बताता है कि कोई संख्या किस श्रेणी में आती है, जिससे आप अनुमान लगाने के बजाय नमूने प्राप्त कर सकते हैं। श्रेणियों के बारे में अधिक जानकारी ICU संदेश प्रारूप पोस्ट में है।

स्नैपशॉट का जाल

स्नैपशॉट और i18n एक बुरा मेल हैं। एक स्थानीयकृत कंपोनेंट का स्नैपशॉट उसमें मौजूद प्रत्येक स्ट्रिंग को एनकोड करता है: जब कोई अनुवादक पुर्तगाली में टाइपो सुधारता है, तो एक पास होने वाला टेस्ट फेल हो जाता है, ऐसी फ़ाइल में जिसका समीक्षक मूल्यांकन नहीं कर सकता। कुछ समय बाद, डेवलपर्स बिना डिफ देखे -u चलाने लगते हैं, और स्नैपशॉट का सारा अर्थ समाप्त हो जाता है।

यदि आप स्नैपशॉट चाहते हैं, तो उन्हें केवल एक लोकेल में लें और इसे सामग्री जांच के बजाय संरचनात्मक जांच मानें। लोकेल-विशिष्ट सब कुछ स्पष्ट असर्शन में होना चाहिए।

केवल रेंडरिंग ही नहीं, नेगोशिएशन का भी परीक्षण करें

उत्पादन में सबसे आम i18n बग गायब स्ट्रिंग नहीं है। यह गलत लोकेल का चयन है: URL /fr/ कहता है, क्लाइंट navigator.language पढ़ता है, और दोनों असहमत होते हैं।

रिज़ॉल्यूशन क्रम का सीधे परीक्षण करें, एक शुद्ध फ़ंक्शन के रूप में, किसी भी कंपोनेंट से अलग:

it("सहेजी गई प्राथमिकता पर URL को प्राथमिकता देता है", () => {
  expect(resolveLocale({ url: "/fr/about", stored: "de", header: "ja" })).toBe(
    "fr"
  );
});

it("जब URL में कोई उपसर्ग नहीं होता है तो हेडर पर वापस जाता है", () => {
  expect(resolveLocale({ url: "/about", stored: null, header: "ja" })).toBe(
    "ja"
  );
});

यह सबसे मूल्यवान i18n टेस्ट है जो अधिकांश कोडबेस में गायब होता है, और इसके लिए किसी DOM की आवश्यकता नहीं होती है।

क्या कहाँ चलाएं

• यूनिट: लोकेल नेगोशिएशन, फॉर्मैटर, बहुवचन श्रेणियां। तेज़, बिना DOM के।
• कंपोनेंट: प्रति लोकेल एक प्रोवाइडर-आधारित रेंडर, भूमिकाओं और कच्ची कुंजियों की अनुपस्थिति की जांच।
• कवरेज: एक डेटा-संचालित टेस्ट जो यह सुनिश्चित करता है कि कोई भी आवश्यक लोकेल गायब नहीं है।
• विजुअल या एंड-टू-एंड: स्यूडोलॉकेल पास और एक RTL पेज, क्योंकि वे विफलताएं दृश्यमान होती हैं।

प्रत्येक कमिट पर पाइपलाइन में पहले तीन को रखें। अंतिम को हर पुश पर चलाना महंगा और नाइटली बिल्ड में चलाना बेहतर है।

सामान्य गलतियाँ

• हर जगह सटीक शब्दों पर जोर देना। कुछ ही महीनों में टेस्ट सुइट के हटा दिए जाने की गारंटी देता है।
• स्थानीयकृत कंपोनेंट्स का स्नैपशॉट लेना। अनुवादक बिल्ड तोड़ते हैं और समीक्षक बिना पढ़े पास करते हैं।
• केवल डिफ़ॉल्ट लोकेल का परीक्षण करना। वह एकमात्र लोकेल जो गायब नहीं हो सकता।
• बहुवचन के लिए केवल 1 और 2 का परीक्षण करना। उन श्रेणियों को छोड़ देता है जो अंग्रेज़ी में नहीं हैं।
• i18n लाइब्रेरी को पूरी तरह मॉक करना। फिर आप केवल यह परीक्षण कर रहे हैं कि आपका मॉक स्ट्रिंग लौटाता है।
• नेगोशिएशन का परीक्षण कभी न करना। सबसे आम वास्तविक समस्या और परीक्षण करने में सबसे आसान।

आगे पढ़ें

• अपनी सामग्री का परीक्षण: CLI ऑडिट, प्रोग्रामेटिक API और UI असर्शन
• ESLint प्लगइन: हार्डकोडेड स्ट्रिंग्स और अप्रयुक्त सामग्री को पकड़ना
• फॉर्मेटर्स और लोकेल उपयोगिताएँ, जिनमें getHTMLTextDir शामिल है
• विभिन्न फ्रेमवर्क में बेंचमार्क रिपोर्ट
• react-i18next ड्रॉप-इन कम्पैट एडॉप्टर
• अनुपस्थित अनुवादों का पता कैसे लगाएं
• ICU संदेश प्रारूप: बहुवचन, सिलेक्ट और स्केलेटन