2009-03-13 18 views
7

रेल ऐप्स पर सेलेनियम परीक्षणों के साथ आप किस डेटा का उपयोग करते हैं? क्या आप फिक्स्चर से लोड करते हैं? मौजूदा देव डीबी का प्रयोग करें? एक अलग (गैर-स्थिरता) डीबी का प्रयोग करें?फिक्स्चर और सेलेनियम और रेल (ओह मेरा?)

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

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

संपादित करें: मूल रूप से प्रत्येक परीक्षण से पहले जुड़नार लोड करना और नियमित परीक्षण परीक्षणों जैसे प्रत्येक परीक्षण के बाद उन्हें उतारना था। लेकिन इस रिपोर्टिंग डेटा के कारण फिक्स्चर लोड करने में लगभग 15 मिनट लगते हैं। 200+ परीक्षण हैं, और सुइट हर 12 घंटे चलता है। मैं spacetime कप्तान मोड़ कर सकते हैं!

संपादित करें 2: मैं यह भी मानता हूं कि इस बड़े फिक्स्चर का एक खराब गंध है। मुझे यकीन नहीं है कि इसे कैसे कम करना है, हालांकि, रिपोर्ट्स बहुत अधिक डेटा एकत्र करती हैं और सेलेनियम परीक्षणों के मूल्य का अधिकतर यह है कि वे रिपोर्ट का परीक्षण करते हैं।

भले ही यह डेटा का एक छोटा सा सेट है, हालांकि ... यह अभी भी स्कीमा परिवर्तनों के साथ समन्वय रखने के लिए एक और सेट है। (हमारे पास इकाई, कार्यात्मक, और [रेल] एकीकरण परीक्षणों के लिए एक अलग, छोटा सेट है।)

जो मुझे अपने मूल प्रश्न पर वापस लाता है - क्या इसे हाथ से करने के अलावा अन्य विकल्प हैं, या उन्हें प्रत्येक को पुन: उत्पन्न करने के लिए याद रखना पहर?

+0

प्रश्न असंबद्ध: क्या आपने रेलवे 3 के साथ सेलेनियम काम करने में कामयाब रहे हैं? किसी को? –

उत्तर

3

यदि आप कर सकते हैं, तो सबसे अच्छी संभव बात यह है कि प्रत्येक सेलेनियम परीक्षण में इसका अपना डेटा स्टेटस होता है (यानी: डीबी टेबल गिराए जाते हैं और फिर से बनाए जाते हैं, बूटस्ट्रैप डेटा फिर से डाला जाता है, और कैश साफ़ हो जाते हैं)। यह आसान होने के मुकाबले आसान है और आम तौर पर केवल तभी संभव है जब परियोजना शुरू से ही इसकी योजना बनाई जाए।

अगली सबसे अच्छी बात यह है कि प्रत्येक टेस्ट सूट/रन के लिए एक सतत डीबी स्थिति हो। यह उतना अच्छा नहीं है क्योंकि अब एक मजबूत मौका है कि कुछ परीक्षण पहले रन परीक्षणों की सफलता पर निर्भर होंगे, जिससे वास्तविक विफलताओं बनाम झूठी नकारात्मकताओं की पहचान करना मुश्किल हो जाएगा।

सबसे खराब मामला, आईएमओ, एक स्थिर डीबी का उपयोग करना है जिसमें प्रत्येक परीक्षण रन तिथि को बदलता है। यह लगभग हमेशा समस्याओं का कारण बनता है और आमतौर पर "परियोजना गंध" होता है।इसे "सही रास्ता" (फिर से, आईएमओ) करने की कुंजी किसी भी राज्य/स्कीमा परिवर्तन के बारे में सतर्क रहना और स्वचालित परीक्षण/निर्माण प्रक्रिया के हिस्से के रूप में इसे कैप्चर करना है।

रेल पहले से ही माइग्रेशन के साथ एक अच्छा काम करता है, इसलिए उनका लाभ उठाएं! आपकी स्थिति जानने के बिना, मैं आमतौर पर पूर्ण डीबी के स्नैप के खिलाफ सेलेनियम परीक्षण चलाने की आवश्यकता पर सवाल उठाता हूं। अधिकांश डीबी स्वचालित परीक्षण के लिए 1 एमबी से भी कम तक (या चाहिए) को डिलीवरी कर सकते हैं, स्वचालित स्कीमा माइग्रेशन और डेटा रीसेट को और अधिक कुशल बनाते हैं।

केवल समय मैं सेलेनियम परीक्षण के लिए बड़े पैमाने पर डीबीएस के लिए एक "वैध" कारण देखा है जब डीबी ही जिसमें डेटा आवेदन प्रवाह को प्रभावित करता है "तर्क डेटा" के बड़े हिस्से में शामिल है (लगता है: डेटा के आधार पर यूआई)।

+0

अच्छी सलाह। इस मामले में, हालांकि, फिक्स्चर लोड करने में लगभग 15 मिनट लगते हैं, इसलिए यदि मैंने प्रत्येक टेस्ट से पहले उन्हें लोड और अनलोड किया है, तो सूट को चलाने में 48 घंटे लगेंगे। –

+0

(...जारी रखा गया) लेकिन, चूंकि मेरा रिपोर्टिंग डेटा केवल पढ़ने के लिए है, शायद मुझे सूट के लिए एक बार लोड करने का कोई तरीका मिल सकता है, जबकि प्रत्येक परीक्षण के लिए अभी भी अनलोडिंग और अन्य फिक्स्चर लोड हो रहा है। –

1

मैं एक बहुत बड़ा सेलेनियम परीक्षण सूट के साथ एक परियोजना पर वर्तमान में हूँ - वास्तव में, एक सेलेनियम ग्रिड के लिए लिखा गया था - और हमारे परीक्षणों (संदर्भ डेटा की एक छोटी राशि का उपयोग हालांकि हम रेल YAML जुड़नार का उपयोग नहीं करते) और विशेष परीक्षणों के लिए आवश्यक एक-ऑफ डेटा के लिए ऑब्जेक्ट कारखानों।

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

उदा। देखें ग्रिथ पर पॉल ग्रॉस का rake commit tasks

+0

धन्यवाद, ब्रायन, यह बहुत उपयोगी है। मैंने पूर्व-चेकइन हुक के रूप में पुनर्जन्म को स्वचालित नहीं माना था। –

2

मुझे लगता है कि आप दो सवाल है कि यहाँ गुंथी होती हैं, पूछ रहे हैं तो अगर मैं इसे तोड़ने के लिए कर रहा हूँ:

  • आप में और अपने डीबी से बाहर जल्दी से परीक्षण डेटा प्राप्त करना चाहते हैं और जुड़नार नहीं हैं यह तुम्हारे लिए कर रहा है
  • आप एक स्कीमा परिवर्तन से जला दिया गया है और आप सुनिश्चित हैं कि जो कुछ भी आप आठ पुनरावृत्तियों थीम की आवश्यकता नहीं है "परीक्षण डाटा के साथ नगण्य ... अभी भी" बनाना चाहते :)

आप ' मुझे यहां कुछ विकल्प मिल गए हैं जिन्हें मैंने नीचे छोड़ दिया है। क्योंकि आप ओरेकल उल्लेख किया है मैं यहाँ ओरेकल प्रौद्योगिकी का उपयोग कर रहा हूँ, लेकिन एक ही बात अन्य डीबी प्लेटफार्मों (जैसे Postgresql) के लिए सच है:

  1. रैक tesks कि फोन PL/SQL स्क्रिप्ट डेटा उत्पन्न करने के लिए, बुरा भयानक बुराई विचार, ऐसा तब तक न करें जब तक कोई अन्य विकल्प न हो। मैंने इसे एक परियोजना पर किया जिसकी कुछ बुनियादी ढांचे वास्तुकला परीक्षणों के लिए अरबों पंक्तियों में लोड करने की आवश्यकता थी। मैं अभी भी इसके बारे में सोल्क।
  2. अपने डीबी को डंप प्रारूप में प्राप्त करें। तेजी से बाइनरी डंप के लिए एक्सपी/आईपी और डेटा पंप उपयोगिताएं देखें। यह आपको आपके डीबी के त्वरित सेटअप और टियरडाउन की अनुमति देगा। निश्चित रूप से एक रेल परियोजना पर मैंने काम किया था, हमने डेटाबेस को एक्सप/आईपी करने के लिए रेक कार्यों का इस्तेमाल किया था, जिसमें एक मिनट से कम में 300k रिकॉर्ड थे। एसक्यूएल लोडर जो तार्किक डंप उपयोगिता है, इसकी तार्किक धीमी गति के रूप में जांचें और आपको SQL लोडर को डंप को समझने में सहायता करने के लिए नियंत्रण स्क्रिप्ट प्राप्त करने की आवश्यकता है। हालांकि, लॉजिकल डंप का लाभ यह है कि आप डेटा को नवीनतम प्रारूप में मालिश करने के लिए उन पर रूपांतरण स्क्रिप्ट चला सकते हैं। अफसोस की बात है कि फिक्स्चर की तरह ही ये सभी टूल्स स्कीमा में बदलने के लिए बहुत संवेदनशील हैं।
  3. डेटा nicer की पीढ़ी बनाने के लिए Machinist या Factory Girl जैसे प्लगइन का उपयोग करें। आप अभी भी डीबी सेट अप करने के लिए ActiveRecord का उपयोग करने का जुर्माना लगाते हैं लेकिन ये नकली ऑब्जेक्ट जेनरेटर आपको माइग्रेशन के करीब रहने में मदद करेंगे और फिक्स्चर से बनाए रखने के लिए बहुत कम परेशानी हैं।
  4. दृष्टिकोण 2 और 3 जोड़ें। यहां क्या होता है कि आप Machinst कहने के साथ कुछ परीक्षण डेटा बनाते हैं। आप उस टेस्ट डेटा को डंप पर निर्यात करते हैं और फिर प्रत्येक टेस्ट रन के दौरान डंप को फिर से लोड करते हैं। जब स्कीमा बदलता है Machinist कॉन्फ़िगरेशन को अद्यतन करें और पुनः निर्यात करें।

आशा है कि मदद करता है।

संबंधित मुद्दे