आप बग के लिए टीडीडी को कैसे तय कर सकते हैं जिसे केवल तय किए जाने के बाद ही परीक्षण किया जा सकता है।


13

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

मेरी समस्या यह है कि मुझे शुरू में पता नहीं है कि इस बग को कैसे ठीक किया जाए और जिस तरह से मैं एक परीक्षा लिख ​​सकता हूं उसके बाद ही मैंने इसे ठीक किया है।

जैसे एक साधारण फ़ंक्शन में let sum = (a, b) => a - b, आप किसी भी कोड को लिखने से पहले क्यों sum(1, 2)नहीं के बराबर एक परीक्षा लिख ​​सकते हैं 3

जिस मामले में मैं वर्णन कर रहा हूं, मैं परीक्षण नहीं कर सकता, क्योंकि मुझे नहीं पता कि सत्यापन क्या है (मुझे नहीं पता कि क्या होना चाहिए)।

वर्णित समस्या का हल है:

let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';

document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);

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

इस समस्या के लिए TDD दृष्टिकोण क्या होगा? कोड अनिवार्य या वैकल्पिक होने से पहले परीक्षण लिख रहा है?


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

@ किलियन फोथ: मैं प्रश्न शीर्षक बदलकर आपके अच्छे इरादों को देखता हूं, लेकिन आपके द्वारा मेरे उत्तर के अमान्य हिस्सों को संपादित किया जाता है। इसके अलावा, आपके नए शीर्षक IMHO प्रश्न निकाय के लिए अच्छी तरह से फिट नहीं था। इसलिए मैंने रोलबैक किया, कोई अपराध नहीं।
डॉक ब्राउन

जवाबों:


26

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

  • ग्राफ़िकल यूज़र इंटरफ़ेस के एक निश्चित व्यवहार का स्वचालित रूप से परीक्षण कैसे करें?

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

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

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


सामान्य यूआई परीक्षण में गैर-तुच्छ है; आप जनरेट की गई इमेज को पिन कर सकते हैं, आप अनुकरण / स्वचालित कर सकते हैं, आप मैक्रो रिकॉर्ड कर सकते हैं, आप एक मालिकाना समाधान का उपयोग कर सकते हैं, आप मैन्युअल परीक्षण का उपयोग कर सकते हैं, स्थिति पर निर्भर करता है और आपके प्रोजेक्ट के लिए स्वचालित यूआई परीक्षण कितना आवश्यक है।
गूढ़

1
@esoterik: हां, और ये सभी स्वचालित तकनीक त्रुटि-प्रवण और भंगुर हैं, जैसा कि मैंने पहले ही लिखा था। केवल गैर-भंगुर दृष्टिकोण मुझे पता है कि मैन्युअल परीक्षण है।
डॉक ब्राउन

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

1
@maximedupre: इस विज्ञापन को एक उपकरण के लिए मिला , जो समस्या का समाधान करने की कोशिश करता है, लेकिन फिर भी लेख सामान्य रूप से मेरे उत्तर से सहमत है।
डॉक ब्राउन

5

इस समस्या के लिए TDD दृष्टिकोण क्या होगा? कोड अनिवार्य या वैकल्पिक होने से पहले परीक्षण लिख रहा है?

एक तरीका स्पाइक समाधान के एनालॉग को लागू करना है ।

जेम्स शोर ने इसे इस तरह वर्णित किया:

जब हमें अधिक जानकारी की आवश्यकता होती है, तो हम छोटे, पृथक प्रयोग करते हैं।

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

चाल: आप अपने उत्पादन कोड में अपनी जांच से वापस ज्ञान लाते हैं , लेकिन आप कोड नहीं लाते हैं । इसके बजाय, आप अपनी अनुशासित डिजाइन तकनीकों का उपयोग करते हुए इसे फिर से बनाते हैं।

मैदान के लिए घोड़े।

संपादित करें:

यदि आप दोष केवल एक मानवीय आंख से देख सकते हैं, तो आप एक परीक्षण को कैसे स्वचालित कर सकते हैं?

मैं थोड़ी अलग वर्तनी का सुझाव देना चाहूंगा: "यदि परीक्षण को स्वचालित करना प्रभावी नहीं है तो आप किसी परीक्षण को कैसे स्वचालित कर सकते हैं?"

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

सॉफ्टवेयर डिज़ाइन के निर्माण के दो तरीके हैं: एक तरीका यह है कि इसे इतना सरल बना दिया जाए कि जाहिर तौर पर कोई कमी न रहे - CAR Hoare

इसलिए जब तीसरे पक्ष के कोड के साथ काम करते हैं, तो हमारे पास कोड का एक बहुत ही पतला खोल होगा जो तीसरे पक्ष के पुस्तकालय के लिए एक प्रॉक्सी के रूप में कार्य करता है। परीक्षण में, हम उस शेल को "टेस्ट डबल" से बदल देते हैं, जो प्रोटोकॉल की पुष्टि करता है , बिना इस चिंता के कि यह वांछित प्रभाव पैदा करता है।

असली तीसरे पक्ष के कोड के साथ हमारे कोड एकीकरण के परीक्षण के लिए, हम अन्य तकनीकों (दृश्य सत्यापन, तकनीकी सहायता कॉल, आशावाद ....) पर भरोसा करते हैं।

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


मुझे प्यार है कि जेम्स शोर का क्या कहना है। मैं वर्तमान में www.letscodejavascript.com स्क्रेंकास्ट का अनुसरण कर रहा हूं और मैं बहुत कुछ सीख रहा हूं। मैंने आपके द्वारा बताए गए लिंक्स को पढ़ा होगा।
मैक्सिममेडुप्रे

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

0

यूआई / जीयूआई के चारों ओर एक अलग परिप्रेक्ष्य, स्वीकृति परीक्षण (सुविधा / व्यापार कार्य प्रवाह केंद्रित परीक्षण) के संबंध में कुछ बेहतर किया जा सकता है।

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

वह हिस्सा जो आपकी स्थिति में विशेष रूप से मदद करेगा, उसे Page Object Model ( https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html ) कहा जाता है । यह कुछ कोड के लिए रन-टाइम GUI की स्पष्ट मैपिंग प्राप्त करता है, या तो तरीकों / घटनाओं / वर्ग के सदस्यों के नामकरण द्वारा।

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

आगे बढ़ते हुए, यह टीम और व्यवसाय की लागत / लाभ पर निर्भर करेगा, इसलिए अपेक्षाओं और विचारों को निर्धारित करने के लिए चर्चा करना एक लाभदायक विषय हो सकता है।


मैं वास्तव में हाल ही में टीडीडी में ई 2 ई / कार्यात्मक परीक्षण (सेलेनियम वेबड्राइवर के साथ) की कोशिश कर रहा था, लेकिन ओवरहेड निश्चित रूप से बहुत बड़ा है जैसा कि आपने कहा। आप एक कुशल डेवलपर नहीं हो सकते हैं और e2e परीक्षणों के साथ TDD कर सकते हैं। मैं POM का उपयोग कर रहा था, लेकिन इसका एकमात्र लाभ मुझे मेरे टेस्ट कोडबेस में एक बेहतर आर्किटेक्चर था।
मैक्सिममेडुप्रे

हाँ, मुझे लगता है कि एक अधिक व्यवहार्य विकल्प जो मैंने विभिन्न कंपनियों से अलग-अलग टीमों के लिए देखा है, एक अधिक मैनुअल SQA प्रक्रिया को शामिल करने के लिए होगा, जहां एक टीम / टीम का सदस्य UI से केवल मैनुअल परीक्षण के लिए नामित होता है। परीक्षणों में ज्यादातर स्क्रीनशॉट और चरण-दर-चरण प्रलेखन हैं। बहुत कम से कम, ऐसा कुछ एक आवेदन की दिशा में परीक्षण के कुछ सबूत पैदा करेगा।
eparham7861

0

भूत की छवि क्या दिखती है? यदि आपने एक ज्ञात रंग की एक डमी ui बनाई है, तो आप अपने ड्रैगेबल घटक को कहां रख सकते हैं? क्या कोई विशिष्ट रंग मौजूद होगा यदि कोई भूत छवि थी।

तब परीक्षण भूत की छवि के रंग की अनुपस्थिति के लिए परीक्षण कर सकता था।

ऐसा परीक्षण उचित टिकाऊ और उल्लेखनीय होगा।


करने योग्य - हाँ। टिकाऊ - निर्भर करता है। बस आपके UI का रंग / थीम बदलने से आपका परीक्षण टूट सकता है, जो मेरे लिए बहुत टिकाऊ नहीं है।
सीन बर्टन

1
आप पूरे यूआई का परीक्षण नहीं करेंगे। आप ड्रैग-एन-ड्रॉप घटक के लिए एक डमी यूआई बनाएंगे।
एबेन स्कोव पेडरसन

मुझे यकीन नहीं है कि आप जो सुझाव दे रहे हैं उसे कैसे पूरा किया जाए। मेरे मामले में एक भूत की छवि उस तत्व की अर्ध-अपारदर्शी प्रतिकृति होगी जिसे खींचा जा रहा है। भूत की छवि हर समय कर्सर का अनुसरण कर रही है, जबकि ड्रैग और ड्रॉप घटित हो रही है।
मैक्सिममेडुप्रे

हाँ। आपको ड्रैगिंग को स्वचालित करना होगा। यह एक इकाई परीक्षण नहीं होगा, बल्कि एक e2e परीक्षण होगा।
एबेन स्कोव पेडर्सन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.