जब तक असली न बन जाए, नकली से काम चलाओ: मॉक डेटा के लिए एक डेवलपर गाइड

एक वाक्य में

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

यह क्या समस्या हल करता है

शुरुआत में था "test"। और "test2"। और "asdf"। जब किसी डेवलपर को यह देखने के लिए कि उनका कोड काम कर रहा है या नहीं, एक फॉर्म भरने या डेटाबेस को पॉप्युलेट करने की ज़रूरत होती थी, तो वे बस कीबोर्ड पर उंगलियां पटक कर नतीजा पा लेते थे। एक यूज़र के लिए यह ठीक है। दस यूज़र्स की लिस्ट के लिए? थोड़ा परेशान करने वाला, लेकिन किया जा सकता है। आखिर में आपके पास एक डेटाबेस होता है जो "User 1," "User 2," और सबसे क्रिएटिव "User 10" जैसे डेटा से भरा होता है।

यह तरीका बहुत जल्दी फेल हो जाता है। क्या होता है जब आपके UI को Maximilian Æon Flux जैसा नाम हैंडल करना पड़ता है? आपके हाथ से टाइप किया गया "Test User" आपको इसके लिए तैयार नहीं करता। क्या होता है जब आपकी डेटाबेस क्वेरी को यह देखने के लिए कि यह परफ़ॉर्मेंट है या नहीं, 10 नहीं बल्कि 50,000 रिकॉर्ड्स के खिलाफ़ टेस्ट करने की ज़रूरत होती है? किसी के पास हाथ से 50,000 नकली यूज़र्स बनाने का समय या इच्छा नहीं होती।

पुराना, खतरनाक समाधान था लाइव प्रोडक्शन डेटाबेस की एक कॉपी ले लेना। सिक्योरिटी और प्राइवेसी के मामले में यह एक बहुत बड़ा खतरा है। किसी डेवलपर के कम-सुरक्षित लैपटॉप पर असली कस्टमर के नाम, ईमेल और व्यक्तिगत जानकारी को उजागर करना एक डेटा ब्रीच को न्योता देना है, जिसके कानूनी परिणाम (नमस्ते, GDPR और HIPAA) एक कंपनी को डुबो सकते हैं।

मॉक डेटा जेनरेटर इस सब का समाधान करते हैं। वे आपको एक बार अपने डेटा का आकार (shape) परिभाषित करने देते हैं, और फिर हज़ारों रिकॉर्ड उगल देते हैं जो असली दिखते और महसूस होते हैं, लेकिन पूरी तरह से मनगढ़ंत होते हैं। यह एक दर्जी द्वारा सूट फिट करने के लिए एक सामान्य पुतले (mannequin) का उपयोग करने और सड़क से किसी भी अनजान व्यक्ति को पकड़ लाने के बीच का अंतर है। पुतला predictable (अनुमानित), सुरक्षित होता है, और उन सभी standard sizes में आता है जिनकी आपको टेस्टिंग के लिए आवश्यकता होती है।

अंदर की कहानी: यह कैसे काम करता है

यह जादू जैसा लग सकता है, लेकिन एक मॉक डेटा जेनरेटर बस टेम्प्लेट्स, बड़ी डिक्शनरीज़ और कंट्रोल्ड रैंडमनेस का एक चतुर संयोजन है।

### टेम्प्लेट्स और प्लेसहोल्डर्स

इसके मूल में, एक जेनरेटर आपके द्वारा प्रदान किए गए एक टेम्प्लेट का उपयोग करता है। यह अक्सर एक JSON ऑब्जेक्ट होता है जो एक सिंगल रिकॉर्ड के लिए ब्लूप्रिंट का काम करता है। वास्तविक वैल्यूज़ के बजाय, आप विशेष प्लेसहोल्डर्स का उपयोग करते हैं जो जेनरेटर को बताते हैं कि आपको किस तरह का डेटा चाहिए।

कल्पना कीजिए कि आपको एक यूज़र ऑब्जेक्ट जेनरेट करना है। आपका टेम्प्लेट कुछ ऐसा दिख सकता है:

{
  "userId": "{{datatype.uuid}}",
  "name": "{{person.fullName}}",
  "email": "{{internet.email}}",
  "signupDate": "{{date.past}}",
  "address": {
    "street": "{{location.streetAddress}}",
    "city": "{{location.city}}",
    "zipCode": "{{location.zipCode}}"
  }
}

प्रत्येक {{...}} एक प्लेसहोल्डर है। आप यह नहीं बता रहे हैं कि नाम "John Smith" है; आप यह बता रहे हैं कि आपको एक नाम चाहिए, और जेनरेटर बाकी का पता लगा लेगा। यह डिक्लेरेटिव अप्रोच शक्तिशाली है क्योंकि आप विशिष्ट कंटेंट पर नहीं, बल्कि स्ट्रक्चर पर ध्यान केंद्रित करते हैं।

### लाइब्रेरीज़ का जादू

तो ये नाम, ईमेल और शहर कहाँ से आते हैं? वे हवा से नहीं आते हैं। उन्हें डेटा-फेकिंग लाइब्रेरीज़ (JavaScript की दुनिया में एक प्रसिद्ध Faker.js है, लेकिन कई भाषाओं के अपने संस्करण हैं) के अंदर विशाल, पहले से कंपाइल की गई लिस्ट्स और एल्गोरिदम से खींचा जाता है।

यहाँ ऊपर दिए गए टेम्प्लेट से एक सिंगल यूज़र रिकॉर्ड कैसे जेनरेट हो सकता है, इसका एक सरल विवरण है:

{{person.fullName}}: लाइब्रेरी में हज़ारों पहले नामों और अंतिम नामों की लिस्ट होती है। यह प्रत्येक से रैंडम तरीके से एक को चुनता है और उन्हें जोड़ता है। random(firstNames) -> "Amelia", random(lastNames) -> "Jones"। नतीजा: "Amelia Jones"।
{{internet.email}}: यह अक्सर अन्य जेनरेट किए गए फ़ील्ड्स पर आधारित होता है। यह अभी बनाए गए "Amelia Jones" को लेकर, इसे amelia.jones में बदल सकता है, और एक लिस्ट से रैंडम रूप से चुने गए डोमेन (@example.com, @mail.net, आदि) को जोड़ सकता है। नतीजा: amelia.jones@example.com।
{{location.city}}: सरल। लाइब्रेरी के पास दुनिया भर के शहरों के नामों की एक विशाल लिस्ट है। यह एक को चुनता है। नतीजा: "Portsmouth"।
{{datatype.uuid}}: यह किसी लिस्ट का उपयोग नहीं करता है। यह एक Universally Unique Identifier (UUID) जेनरेट करने के लिए एक सु-परिभाषित एल्गोरिदम का उपयोग करता है, जैसे f81d4fae-7dec-11d0-a765-00a0c91e6bf6।

जेनरेटर आपके टेम्प्लेट को फ़ील्ड-दर-फ़ील्ड प्रोसेस करता है, प्रत्येक प्लेसहोल्डर के लिए उपयुक्त लाइब्रेरी फ़ंक्शन को कॉल करता है जब तक कि पूरा नकली रिकॉर्ड नहीं बन जाता। 10,000 रिकॉर्ड चाहिए? यह बस इस प्रक्रिया को 10,000 बार दोहराता है।

### डिटरमिनिज्म और सीडिंग

टेस्टिंग के लिए यहाँ एक महत्वपूर्ण विवरण है: क्या होगा यदि आपको हर बार जब आप अपने टेस्ट चलाते हैं तो "रैंडम" डेटा का एक ही सेट चाहिए? यदि आपका टेस्ट "Amelia Jones" नाम के यूज़र की उम्मीद करता है, लेकिन अगली बार चलाने पर उसे "Bob Williams" मिलता है, तो यह फेल हो जाएगा। यहीं पर "सीडिंग" काम आती है।

कंप्यूटर वास्तव में रैंडम होने में बहुत खराब हैं। वे एक चीज़ का उपयोग करते हैं जिसे स्यूडोरैंडम नंबर जेनरेटर (PRNG) कहा जाता है। एक PRNG एक एल्गोरिदम है जो संख्याओं का एक क्रम उत्पन्न करता है जो रैंडम दिखता है, लेकिन वास्तव में पूरी तरह से एक शुरुआती वैल्यू द्वारा निर्धारित होता है जिसे सीड (seed) कहा जाता है।

यदि आप seed = 123 से शुरू करते हैं, तो आपको यह क्रम मिल सकता है: 5, 8, 2, 1, 10, ...
यदि आप इसे seed = 123 के साथ फिर से चलाते हैं, तो आपको बिल्कुल वही क्रम मिलता है: 5, 8, 2, 1, 10, ...
यदि आप seed = 456 से शुरू करते हैं, तो आपको एक बिल्कुल अलग क्रम मिलेगा: 9, 4, 7, 3, 3, ...

अपने मॉक डेटा जेनरेटर को एक सीड प्रदान करके, आप यह सुनिश्चित करते हैं कि हर बार जब यह चलता है, तो यह अपनी लिस्ट्स से उसी "रैंडम" पहले नाम, उसी "रैंडम" अंतिम नाम, और उसी "रैंडम" शहर को उसी क्रम में चुनता है। यह आपको एक ऐसा डेटासेट देता है जो यथार्थवादी और पूरी तरह से रीप्रोड्यूसिबल (reproducible) दोनों है, जो स्थिर, विश्वसनीय ऑटोमेटेड टेस्ट लिखने के लिए 'होली ग्रेल' (holy grail) है।

असल दुनिया की कहानियाँ

थ्योरी तो बढ़िया है, लेकिन देखते हैं कि असल में यह कैसे काम करता है।

### जब यूज़र कार्ड का डिज़ाइन फट गया

एक फ्रंटएंड डेवलपर, चलिए उसे प्रिया कहते हैं, को एक सोशल मीडिया ऐप के लिए एक सुंदर नया यूज़र प्रोफ़ाइल कार्ड बनाने का काम सौंपा गया था। उसने "Jane Doe" और एक स्टैंडर्ड @gmail.com पते को अपने टेस्ट डेटा के रूप में उपयोग करके CSS को सावधानीपूर्वक तैयार किया। कार्ड पिक्सेल-परफेक्ट दिख रहा था। नाम और ईमेल एक लाइन में बड़े करीने से फिट हो रहे थे। उसने फीचर को शिप कर दिया।

अगले दिन, बग रिपोर्ट आने लगीं। Dr. Alessandro O'Connell-Schäfer नाम के एक यूज़र ने साइन अप किया। उसका नाम लेआउट को तोड़ रहा था, तीन लाइनों में लिपट रहा था और उसकी प्रोफ़ाइल तस्वीर को कार्ड से आधा बाहर धकेल रहा था। आइसलैंड के एक अन्य यूज़र के नाम में एक नॉन-ASCII करैक्टर था, जो एक उलझे हुए ? के रूप में दिख रहा था। लेआउट पूरी तरह गड़बड़ था।

सीख: आपका साफ-सुथरा, हार्डकोडेड टेस्ट डेटा एक झूठ है। एक मॉक डेटा जेनरेटर ने जल्दी से विभिन्न लंबाई, हाइफ़न, एपोस्ट्रोफी और अंतरराष्ट्रीय करैक्टर वाले नाम बना दिए होते, जिससे ये UI कमजोरियां असली यूज़र तक पहुंचने से बहुत पहले ही सामने आ जातीं।

### पेजिनेशन परफॉर्मेंस का दुःस्वप्न

एक बैकएंड टीम एक नई ई-कॉमर्स साइट लॉन्च कर रही थी। एक डेवलपर, बेन, /products API एंडपॉइंट के लिए जिम्मेदार था। उसने अपने लोकल डेटाबेस में एक दर्जन टेस्ट प्रोडक्ट बनाए: "Test Book," "Test Shirt," आदि। उसने प्रोडक्ट्स को फेच करने के लिए कोड लिखा, पेजिनेशन (प्रति पेज 25 आइटम) जोड़ा, और सब कुछ flawlessly काम कर रहा था। API 20 मिलीसेकंड में जवाब दे रहा था।

साइट लॉन्च हुई। एक सप्ताह के भीतर, प्रोडक्ट कैटलॉग 30,000 आइटम तक बढ़ गया। अचानक, यूज़र्स ने रिपोर्ट किया कि प्रोडक्ट पेज लोड होने में हमेशा के लिए समय ले रहे हैं या पूरी तरह से टाइम आउट हो रहे हैं। डेटाबेस क्वेरी, जो 12 प्रोडक्ट्स के लिए तुरंत थी, अब विशाल टेबल को स्कैन कर रही थी और पूरा होने में 15 सेकंड से अधिक का समय ले रही थी। ऐप ठप पड़ने लगा था।

सीख: फंक्शनैलिटी का मतलब परफॉर्मेंस नहीं है। परफॉर्मेंस को टेस्ट करने के लिए, आपको यथार्थवादी मात्रा में डेटा की आवश्यकता होती है। हाथ से 12 प्रोडक्ट्स बनाने के बजाय, बेन मिनटों में 50,000 नकली प्रोडक्ट्स बनाने के लिए एक मॉक डेटा जेनरेटर का उपयोग कर सकता था। इससे डेवलपमेंट के दौरान धीमी क्वेरी तुरंत सामने आ जाती, जिससे उसे प्रोडक्शन संकट बनने से पहले एक आवश्यक डेटाबेस इंडेक्स जोड़ने के लिए प्रेरित किया जाता।

### GDPR अनुपालन का डर

एक छोटा स्टार्टअप एक बड़े संभावित निवेशक के लिए डेमो तैयार करने की हड़बड़ी में था। वे चाहते थे कि डेमो यथासंभव वास्तविक लगे। एक जूनियर डेवलपर, मददगार बनने की कोशिश में, एक "शानदार" विचार के साथ आया: उसने प्रोडक्शन डेटाबेस से कनेक्ट किया, पूरी users टेबल (लगभग 2,000 असली कस्टमर) को कॉपी किया, और इसे स्टेजिंग एनवायरनमेंट में लोड कर दिया। डेटा असली था, इसलिए डेमो बहुत अच्छा लग रहा था!

एक हफ्ते बाद, एक सीनियर इंजीनियर को पता चला कि क्या हुआ था। खलबली मच गई। असली कस्टमर के नाम, ईमेल और फ़ोन नंबर एक कम-सुरक्षित स्टेजिंग सर्वर पर पड़े थे, जो पूरी डेवलपमेंट टीम के लिए सुलभ थे। यह GDPR जैसे डेटा प्राइवेसी कानूनों का एक क्लासिक उल्लंघन था। अगर वह डेटा लीक हो गया होता, तो कंपनी को भारी जुर्माना और यूज़र के विश्वास का पूरा नुकसान हो सकता था। वे एक बड़ी मुसीबत से बच गए, लेकिन सफ़ाई का काम तनावपूर्ण और महंगा था।

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

आम गलतियाँ और जाल

एज केस को नज़रअंदाज़ करना। हज़ारों "John Smith" जैसे नाम जेनरेट करना आसान है। लेकिन वास्तव में लंबे नामों का क्या? एपोस्ट्रोफी वाले नाम? अजीब करैक्टर वाले पते? + चिह्न वाले ईमेल? एक अच्छी मॉकिंग रणनीति में ऐसा डेटा जेनरेट करना शामिल है जो विशेष रूप से इन एज केस का परीक्षण करता है, न कि केवल हैप्पी पाथ का।
रिलेशनशिप्स के बारे में भूल जाना। 100 यूज़र्स की लिस्ट और 1000 ऑर्डर्स की लिस्ट जेनरेट करना आसान है। लेकिन हकीकत में, वे ऑर्डर्स उन यूज़र्स के होते हैं। एक आम गलती डिस्कनेक्टेड डेटा जेनरेट करना है। अच्छे मॉकिंग सेटअप आपको रिलेशनशिप्स बनाए रखने की अनुमति देते हैं, उदाहरण के लिए, पहले userId का एक सेट जेनरेट करके, और फिर डेटा इंटीग्रिटी सुनिश्चित करने के लिए orders जेनरेट करते समय उस सेट से चुनकर।
टेस्ट के लिए नॉन-डिटरमिनिस्टिक डेटा बनाना। यदि आपके ऑटोमेटेड टेस्ट एक ऐसे मॉक जेनरेटर पर चलते हैं जो हर बार अलग-अलग डेटा उत्पन्न करता है, तो आपके पास "फ्लेकी" टेस्ट होंगे जो रैंडम रूप से फेल हो जाते हैं। इसे डीबग करना एक दुःस्वप्न है। टेस्टिंग एनवायरनमेंट के लिए हमेशा अपने जेनरेटर को सीड करें ताकि यह सुनिश्चित हो सके कि आपका टेस्ट डेटा 100% रीप्रोड्यूसिबल है।
एक समान वितरण मान लेना। यदि आप एक status फ़ील्ड जेनरेट कर रहे हैं और रैंडम रूप से ["active", "pending", "suspended"] में से चुनते हैं, तो आपको प्रत्येक का लगभग 33% मिलेगा। वास्तविक दुनिया का डेटा शायद ही कभी इतना साफ-सुथरा होता है। आपके पास 98% एक्टिव यूज़र, 1.9% पेंडिंग, और 0.1% सस्पेंडेड हो सकते हैं। कई जेनरेटर आपको वास्तविक दुनिया के डेटा वितरण को अधिक सटीक रूप से मॉडल करने के लिए वेट (weights) निर्दिष्ट करने की अनुमति देते हैं।

यह आपके रडार पर क्यों होना चाहिए

जब भी आपको ऐसे डेटा की आवश्यकता हो जो अभी तक मौजूद नहीं है, जिसका उपयोग नहीं किया जाना चाहिए, या जिसे हाथ से बनाना बहुत थकाऊ है, तो आपको एक मॉक डेटा जेनरेटर का उपयोग करना चाहिए।

इसके बारे में तब सोचें जब आप:

एक नया फीचर बना रहे हों और डेटाबेस टेबल अभी भी खाली हों।
ऑटोमेटेड टेस्ट लिख रहे हों और लगातार, अनुमानित डेटा इनपुट की आवश्यकता हो।
किसी API या डेटाबेस क्वेरी का परफॉर्मेंस टेस्ट कर रहे हों और हज़ारों या लाखों रिकॉर्ड्स का अनुकरण करने की आवश्यकता हो।
एक UI डिज़ाइन कर रहे हों और इसे लंबी स्ट्रिंग्स, अजीब करैक्टर और विविध कंटेंट के साथ स्ट्रेस-टेस्ट करना चाहते हों।
एक प्रोडक्ट डेमो या स्क्रीनकास्ट बना रहे हों और निजी जानकारी उजागर किए बिना यथार्थवादी दिखने वाले डेटा की आवश्यकता हो।
एक नए डेवलपर को ऑनबोर्ड कर रहे हों और उन्हें काम करने के लिए एक पॉपुलेटेड डेटाबेस देना चाहते हों बिना प्रोडक्शन डेटा तक पहुंच दिए।

यह आधुनिक, सुरक्षित और कुशल सॉफ्टवेयर डेवलपमेंट के लिए एक मूलभूत उपकरण है।

और गहराई में जाएं

Faker.js - JavaScript इकोसिस्टम में सबसे लोकप्रिय और व्यापक मॉक डेटा जेनरेशन लाइब्रेरी में से एक का डॉक्यूमेंटेशन। यह देखने के लिए एक बेहतरीन जगह है कि कितने विविध प्रकार के डेटा बनाए जा सकते हैं।
Wikipedia: Test Data Generation - इस कांसेप्ट, इसके इतिहास और इस समस्या के विभिन्न दृष्टिकोणों का एक हाई-लेवल ओवरव्यू।
Wikipedia: Pseudorandom Number Generator (PRNG) - यह सैद्धांतिक आधार कि कैसे "रैंडम" डेटा को सीडिंग के माध्यम से रीप्रोड्यूसिबल (reproducible) बनाया जा सकता है।
GDPR.eu: What is GDPR? - EU के डेटा प्राइवेसी रेगुलेशन का स्पष्टीकरण। नियमों को समझने से यह स्पष्ट करने में मदद मिलती है कि टेस्टिंग के लिए प्रोडक्शन डेटा का उपयोग करना इतना जोखिम भरा क्यों है।
Database Seeding (Laravel Docs) - एक लोकप्रिय वेब फ्रेमवर्क कैसे मॉक डेटा जेनरेशन ("seeders" और "factories" के माध्यम से) को सीधे डेवलपमेंट वर्कफ़्लो में इंटीग्रेट करता है, इसका एक उत्कृष्ट उदाहरण। ये कांसेप्ट किसी भी भाषा या फ्रेमवर्क में ट्रांसफर किए जा सकते हैं।