आप एक एनकोडर का परीक्षण कैसे करते हैं?

Question

मेरे पास कुछ इस तरह है:

public byte[] EncodeMyObject(MyObject obj)

मैं इस तरह से यूनिट परीक्षण कर रहा हूं:

byte[] expectedResults = new byte[3]{ 0x01, 0x02, 0xFF };
Assert.IsEqual(expectedResults, EncodeMyObject(myObject));

संपादित करें: मैंने जिन दो तरीकों को देखा है वे प्रस्तावित हैं:

1) उपरोक्त उदाहरण की तरह हार्डकोडेड अपेक्षित मान का उपयोग करना।

2) एन्कोडेड बाइट सरणी को डीकोड करने के लिए एक डिकोडर का उपयोग करना और इनपुट / आउटपुट ऑब्जेक्ट्स की तुलना करना।

विधि 1 के साथ मुझे जो समस्या दिख रही है, वह यह है कि यह बहुत भंगुर है और इसके लिए बहुत कठिन कोडित मूल्यों की आवश्यकता है।

विधि 2 के साथ समस्या यह है कि एनकोडर का परीक्षण डिकोडर पर सही ढंग से काम करने पर निर्भर करता है। यदि एनकोडर / डिकोडर को समान रूप से (एक ही स्थान पर) तोड़ा जाता है, तो परीक्षण झूठी सकारात्मकता उत्पन्न कर सकते हैं।

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

Comments

कैसे करता है myObjectसे जाना myObjectकरने के लिए { 0x01, 0x02, 0xFF }? क्या उस एल्गोरिथ्म को तोड़कर परीक्षण किया जा सकता है? मेरे द्वारा पूछे जाने का कारण वर्तमान में है, ऐसा लगता है कि आपके पास एक परीक्षण है जो साबित करता है कि एक जादू की चीज एक और जादू की चीज पैदा करती है। आपका एकमात्र विश्वास यह है कि एक इनपुट एक आउटपुट का उत्पादन करता है। यदि आप एल्गोरिथ्म को तोड़ सकते हैं, तो आप एल्गोरिथ्म में और अधिक आत्मविश्वास प्राप्त कर सकते हैं, और जादुई इनपुट और आउटपुट पर कम निर्भर हो सकते हैं।

— एंथनी Pegram

@Codism यदि एक ही स्थान पर एनकोडर और डिकोडर को तोड़ा जाए तो क्या होगा?

— ConditionRacer

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

— ब्लरफ्ल

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

— एंथनी पेग्राम

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

— डैनियल कपलान

Answer 1

आप वहां एक अप्रिय स्थिति में हैं। यदि आपके पास एक स्थिर प्रारूप था जिसे आप एन्कोडिंग कर रहे थे, तो आपका पहला तरीका जाने का रास्ता होगा। यदि यह सिर्फ आपका अपना स्वरूप था, और किसी को भी दूसरी विधि से डिकोड नहीं करना था, तो जाने का रास्ता होगा। लेकिन आप वास्तव में उन श्रेणियों में फिट नहीं हैं।

मैं क्या कर रहा हूँ अमूर्त के स्तर से चीजों को तोड़ने की कोशिश करेंगे।

तो मैं बिट स्तर पर कुछ के साथ शुरू करूँगा, कि मैं कुछ इस तरह का परीक्षण करूँगा

bitWriter = new BitWriter();
bitWriter.writeInt(42, bits = 7);
assertEqual( bitWriter.data(), {0x42} )

तो विचार यह है कि बिटकॉइन जानता है कि सबसे आदिम प्रकार के खेतों को कैसे लिखना है, जैसे कि स्याही।

और अधिक जटिल प्रकारों का उपयोग करके परीक्षण किया जाएगा:

bitWriter = new BitWriter();
writeDate(bitWriter, new Datetime(2001, 10, 4));

bitWriter2 = new BitWriter();
bitWriter2.writeInt(2001, 12)
bitWriter2.writeInt(10, 4)
bitWriter2.writeInt(4, 6)

assertEquals(bitWriter.data(), bitWriter2.data() )

ध्यान दें कि यह किसी भी ज्ञान से बचा जाता है कि वास्तविक बिट्स कैसे पैक किए जाते हैं। यह पिछले परीक्षण द्वारा परीक्षण किया गया है, और इस परीक्षण के लिए हम बहुत ज्यादा सिर्फ यह मानेंगे कि यह काम करता है।

तब हम अमूर्त के अगले स्तर पर होंगे

bitWriter = new BitWriter();
encodeObject(bitWriter, myObject);


bitWriter2 = new BitWriter();
bitWriter2.writeInt(42, 32)
writeDate(bitWriter2, new Datetime(2001, 10, 4));
writeVarString(bitWriter2, "alphanumeric");

assertEquals(bitWriter.data(), bitWriter2.data() )

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

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

Comments

यह मुझे पंसद है। मुझे लगता है कि यह कुछ अन्य टिप्पणीकारों ने इसे छोटे टुकड़ों में तोड़ने के बारे में कहा था। यह पूरी तरह से समस्या से बचता है जब कल्पना बदल जाती है, लेकिन यह इसे बेहतर बनाता है।

— सशर्त

Answer 2

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

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

Comments

मान लीजिए आप डिकोडर का उपयोग करते हैं और मूल्यों की तुलना करते हैं। क्या होगा यदि एनकोडर और डिकोडर दोनों एक ही स्थान पर टूट गए हों? एनकोडर गलत तरीके से एन्कोड करता है, और डिकोडर गलत तरीके से डिकोड करता है, लेकिन इनपुट / आउटपुट ऑब्जेक्ट सही हैं क्योंकि प्रक्रिया दो बार गलत तरीके से की गई थी।

— सशर्त

@ जस्टिन 984 तो तथाकथित "टेस्ट वैक्टर" का उपयोग करें, इनपुट / आउटपुट जोड़े को जानें जो आप एक एनकोडर और डिकोडर का परीक्षण करने के लिए सटीक रूप से उपयोग कर सकते हैं

— शाफ़्ट सनकी

@ratchet फ्रीक जो मुझे अपेक्षित मूल्यों के साथ परीक्षण के लिए वापस लाता है। जो ठीक है, वही मैं वर्तमान में कर रहा हूं, लेकिन यह थोड़ा भंगुर है इसलिए मैं यह देखना चाह रहा था कि क्या बेहतर तरीके हैं।

— सशर्त

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

— user281377

लापता ज्ञान के कारण डिकोडर और एन्कोडर्स दोनों को प्रभावित करने वाले कीड़े को पकड़ने में मदद करने के लिए, अन्य विक्रेताओं के साथ एनकोडर आउटपुट प्राप्त करने का प्रयास करें; और तीसरे पक्ष के डिकोडर पर अपने एनकोडर के आउटपुट का परीक्षण करने का भी प्रयास करें। इसके आसपास कोई विकल्प नहीं है।

— रवांग

Answer 3

परीक्षण है कि encode(decode(coded_value)) == coded_valueऔर decode(encode(value)) == value। आप चाहें तो परीक्षणों को एक यादृच्छिक इनपुट दे सकते हैं।

यह अभी भी संभव है कि एनकोडर और डिकोडर दोनों को मानार्थ तरीके से तोड़ा जाए, लेकिन जब तक आपको एन्कोडिंग मानक की वैचारिक गलतफहमी न हो, तब तक इसकी संभावना कम लगती है। एनकोडर और डिकोडर के हार्डकोडेड टेस्ट करना (जैसे कि आप पहले से ही कर रहे हैं) को उससे बचाव करना चाहिए।

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

Comments

मैं मानता हूं कि एक पूरक एनकोडर / डिकोडर त्रुटि सामान्य रूप से संभव नहीं है। मेरे विशिष्ट मामले में, एनकोडर / डिकोडर कक्षाओं के लिए कोड एक डेटाबेस से नियमों के आधार पर किसी अन्य उपकरण द्वारा उत्पन्न होता है। इसलिए पूरक त्रुटियां कभी-कभार होती हैं।

— ConditionRacer

Complimentary मानार्थ त्रुटियाँ ’कैसे हो सकती हैं? इसका मतलब है कि एन्कोडेड फॉर्म के लिए एक बाहरी विनिर्देश है, और इसलिए एक बाहरी डिकोडर है।

— केविन क्लाइन

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

— सशर्त

यदि एनकोडर ROT13 को लागू करने वाला था, लेकिन गलती से ROT14 और डिकोडर ने भी किया था, तो डिकोड (एनकोड ('a)) ==' a 'लेकिन एनकोडर अभी भी टूटा हुआ है। उससे बहुत अधिक जटिल चीजों के लिए, शायद यह बहुत कम संभावना है कि उस तरह की बात होगी, लेकिन सैद्धांतिक रूप से यह हो सकता है।

— माइकल शॉ

@MichaelShaw सिर्फ एक सामान्य ज्ञान का टुकड़ा है, ROT13 के लिए एनकोडर और डिकोडर समान हैं; ROT13 इसका अपना विलोम है। यदि आपने गलती से ROT14 लागू किया है, तो decode(encode(char))यह बराबर नहीं होगा char(यह बराबर होगा char+2)।

— टॉम मार्थेनल

Answer 4

आवश्यकताओं का परीक्षण ।

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

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

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

Answer 5

आपके द्वारा उपयोग किए जा रहे परीक्षण ढाँचे और प्रतिमान के आधार पर, आप अभी भी इसके लिए अरेंज एक्ट एस्टर पैटर्न का उपयोग कर सकते हैं जैसे आपने कहा है।

[TestMethod]
public void EncodeMyObject_ForValidInputs_Encodes()
{
    //Arrange object under test
    MyEncoder encoderUnderTest = new MyEncoder();
    MyObject validObject = new MyOjbect();
    //arrange object for condition under test

    //Act
    byte[] actual = encoderUnderTest.EncodeMyObject(myObject);

    //Assert
    byte[] expected = new byte[3]{ 0x01, 0x02, 0xFF };
    Assert.IsEqual(expected, actual);
}

आपको EncodeMyObject()उनमें से प्रत्येक के लिए वैध और अमान्य मानदंडों के लिए परीक्षण करने के लिए आवश्यकताओं का पता होना चाहिए और उनमें से प्रत्येक को व्यवस्थित करके और expectedडिकोडर के लिए , इसी तरह अपेक्षित परिणाम को हार्डकोड करने के लिए उपयोग करना चाहिए।

चूँकि अपेक्षित हार्ड कोडेड हैं, यदि आप बड़े पैमाने पर बदलाव कर चुके हैं, तो ये नाजुक हो जाएंगे।

आप संचालित कुछ पैरामीटर ( Pex पर एक नज़र ) के साथ स्वचालित करने में सक्षम हो सकते हैं या यदि आप DDD या BDD कर रहे हैं, तो gerkin / ककड़ी पर एक नज़र डालें ।

Answer 6

आपको यह तय करना है कि आपके लिए क्या महत्वपूर्ण है।

क्या आपके लिए यह महत्वपूर्ण है कि एक वस्तु गोल यात्रा से बच जाए, और सटीक तार प्रारूप वास्तव में महत्वपूर्ण नहीं है? या सटीक तार प्रारूप आपके एनकोडर और डिकोडर की कार्यक्षमता का एक महत्वपूर्ण हिस्सा है?

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

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