आप जो कर रहे हैं वह "हर किसी के साथ एक पर्यावरण में मिलकर काम करता है" से "हर किसी का अपना विकास वातावरण" होता है। मुख्य लाभ यह है कि हर कोई एक दूसरे के पैर पर कदम नहीं उठाएगा।
अन्य लाभों में एक विषम विकास वातावरण शामिल है, यह है कि यदि हर कोई एक ही मशीन पर विकसित हो रहा है तो सॉफ्टवेयर उस सेटअप पर निर्भर हो जाएगा क्योंकि डेवलपर्स आलसी हैं। यदि हर कोई अलग-अलग वातावरण में विकसित होता है, यहां तक कि एक ही सामान के थोड़ा अलग संस्करणों के साथ, उन्हें इससे निपटने के लिए और अधिक मजबूत कोड लिखने के लिए मजबूर किया जाएगा।
जैसा कि आपने देखा है, मुख्य दोष, पर्यावरण स्थापित करना कठिन है। विशेष रूप से, यह सुनिश्चित करना कि डेटाबेस काम करता है।
सबसे पहले, प्रत्येक डेवलपर का अपना डेटाबेस होना चाहिए। इसका मतलब यह नहीं है कि उनके पास सभी का अपना डेटाबेस सर्वर है (हालांकि यह विषम उद्देश्यों के लिए अच्छा है) लेकिन उनके पास अपना स्वयं का डेटाबेस उदाहरण होना चाहिए जो वे नियंत्रित करते हैं।
दूसरा, आपको में एक स्कीमा होना चाहिए और न कि डेटाबेस में जो भी हो। यह एक संस्करण नियंत्रित फ़ाइल में होना चाहिए।
तीसरा, एक नया डेटाबेस स्थापित करना स्वचालित होना चाहिए। यह डेवलपर्स को बिना किसी परेशानी के एक साफ डेटाबेस स्थापित करने देता है।
चौथा, आपको उस डेटाबेस में दिलचस्प परीक्षण डेटा प्राप्त करने की आवश्यकता होगी। यहां वह जगह है जहां चीजें दिलचस्प होती हैं ...
आपके पास ऐसा करने के लिए कई मार्ग हैं।
सबसे पहले मौजूदा डेटाबेस का डंप बनाना है जिसमें यथार्थवादी डेटा है, निश्चित रूप से sanitized। यह आसान है, और यथार्थवादी डेटा प्रदान करता है, लेकिन यह बहुत भंगुर है। डेवलपर्स को अपने परीक्षण करने के लिए दिलचस्प डेटा खोजने के लिए चारों ओर शिकार करना होगा। वह डेटा अगले डंप में बदल सकता है, अपने परीक्षण तोड़ सकता है। या यह बिल्कुल अस्तित्व में नहीं हो सकता है।
दूसरा "परीक्षण जुड़नार" लिखना है। असल में प्रत्येक परीक्षण डाटाबेस को परीक्षण डेटा के साथ पॉप्युलेट करता है। इसका विकास करने वाले को सटीक डेटा प्राप्त करने की इजाजत देने का लाभ है, और पता है कि डेटाबेस में राज्य ठीक है। दोष यह है कि यह बहुत समय ले सकता है, और अक्सर डेटा बहुत साफ है। डेटा में सभी किरकिरा वास्तविक डेटा नहीं होंगे जो वास्तविक बग का कारण बन सकते हैं।
तीसरा डेटाबेस तक पहुंच नहीं है और इसके बजाय सभी डेटाबेस कॉल "मॉक" है। आप उन सभी विधियों को चालित करते हैं जो आमतौर पर डेटाबेस डेटा को बदले में परीक्षण डेटा लौटते हैं। यह टेस्ट फिक्स्चर लिखने की तरह है, और इसमें बहुत अधिक कमी और लाभ हैं, लेकिन यह एफएआर अधिक आक्रामक है। ऐसा करना मुश्किल होगा जब तक कि आपके सिस्टम को ऐसा करने के लिए डिज़ाइन नहीं किया गया हो। यदि आपका डेटाबेस कॉल करता है तो यह वास्तव में कभी भी परीक्षण नहीं करता है।
अंत में, आप पुस्तकालयों का एक सेट बना सकते हैं जो आपके लिए अर्ध-यादृच्छिक डेटा उत्पन्न करते हैं। मैं वीडियो गेम के बाद यह "सिम्स तकनीक" कहता हूं जहां आप नकली परिवार बनाते हैं, उन्हें यातना देते हैं और फिर उन्हें फेंक देते हैं। उदाहरण के लिए, मान लीजिए कि आपके पास उपयोगकर्ता ऑब्जेक्ट है जिसके लिए नाम, आयु, भुगतान ऑब्जेक्ट और सत्र ऑब्जेक्ट की आवश्यकता है। किसी उपयोगकर्ता का परीक्षण करने के लिए आप अलग-अलग नाम, आयु, भुगतान करने की क्षमता और लॉगिन स्थिति वाले उपयोगकर्ताओं को चाह सकते हैं। नाम, आयु, भुगतान और सत्र के लिए परीक्षण डेटा जेनरेट करने के लिए आपको आवश्यक सभी को नियंत्रित करने के लिए। तो आप उम्र उत्पन्न करने के लिए नाम उत्पन्न करने के लिए एक फ़ंक्शन लिखते हैं। यह एक सूची से यादृच्छिक रूप से चुनने के रूप में सरल हो सकता है। फिर आप एक भुगतान ऑब्जेक्ट और एक सत्र वस्तु बनाने के लिए एक लिखते हैं। डिफ़ॉल्ट रूप से, सभी गुण यादृच्छिक होंगे, लेकिन मान्य ... जब तक आप अन्यथा निर्दिष्ट नहीं करते हैं। उदाहरण के लिए...
# Generate a random login session, but guarantee that it's logged in.
session = Session.sim(logged_in = true)
फिर आप इसका उपयोग एक दिलचस्प उपयोगकर्ता को एक साथ रखने के लिए कर सकते हैं।
# A user who is logged in but has an invalid Visa card
# Their name and age will be random but valid
user = User.sim(
session = Session.sim(logged_in = true),
payment = Payment.sim(invalid = true, type = "Visa"),
);
यह परीक्षण जुड़नार के सभी फायदे हैं, लेकिन जब से डेटा के कुछ अप्रत्याशित है यह वास्तविक डेटा के कुछ लाभ है। अपने डिफ़ॉल्ट सिम और रैंड फ़ंक्शंस में "रोचक" डेटा जोड़ना व्यापक प्रतिक्रियाओं में होगा। उदाहरण के लिए, random_name पर यूनिकोड नाम जोड़ना संभवतः सभी प्रकार की रोचक बग की खोज करेगा! दुर्भाग्यवश यह महंगा है और निर्माण करने में समय लगता है।
वहां आपके पास है। दुर्भाग्यवश डेटाबेस समस्या का कोई आसान जवाब नहीं है, लेकिन मैं आपको केवल उत्पादन डेटाबेस की प्रतिलिपि बनाने के लिए आग्रह करता हूं क्योंकि यह लंबे समय तक खोने वाला प्रस्ताव है। आप संभवतः सभी विकल्पों का एक संकर करेंगे: प्रतिलिपि, फिक्स्चर, मॉकिंग, अर्द्ध-यादृच्छिक डेटा।
आप उत्पादन से देव डेटाबेस के लिए एक तरह से प्रतिकृति होने पर विचार किया है? दो प्रतियां, जिनमें से एक नियमित आधार पर दूसरे को ओवरराइट करता है? फिर आप देव प्रतिलिपि से जुड़ते हैं, और आपके द्वारा किए गए कुछ भी लंबे समय तक "छड़ी" नहीं करेंगे। – Borealid
बस स्पष्ट करने के लिए, ऐसा लगता है कि यह गिट के साथ नहीं है, लेकिन "विकास परीक्षण पर काम करता है" से आपकी विकास शैली को बदलने के साथ "हर किसी का अपना परीक्षण वातावरण होता है"। आपका विशेष प्रश्न परीक्षण डेटाबेस के साथ क्या करना है इसके बारे में है। क्या मैं सही हूँ? – Schwern
@ बॉरिडाइड मुझे आश्चर्य है कि एक तरफा * आंशिक * प्रतिकृति करना संभव है, जैसे सीमा 50 या कुछ के साथ एक चुनिंदा कथन करना। इस तरह हम स्थानीय डेटाबेस को काफी छोटा रख सकते हैं और अपना खुद का कस्टम यादृच्छिक डेटा भी जोड़ सकते हैं। – hobbes3