💭 👨🏽‍🎤 💆🏻 चिंता को कैसे रोकें और संपत्ति-आधारित परीक्षण लिखना शुरू करें 🚣🏾 💚 🐊

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

तीन छोटे परीक्षणों में कुंजी-मूल्य भंडारण का परीक्षण

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

कुंजी द्वारा मान लिखें
जाँच करें कि कोई प्रविष्टि वांछित कुंजी के साथ मौजूद है या नहीं
कुंजी द्वारा मूल्य पढ़ें
दर्ज वस्तुओं की एक सूची प्राप्त करें
रिपॉजिटरी की एक प्रति प्राप्त करें

शास्त्रीय उदाहरण-आधारित दृष्टिकोण में, एक विशिष्ट परीक्षण कुछ इस तरह दिखाई देगा:

storage = Storage() storage['a'] = 42 assert len(storage) == 1 assert 'a' in storage assert storage['a'] == 42

या तो:

 storage = Storage() storage['a'] = 42 storage['b'] = 73 assert len(storage) == 2 assert 'a' in storage assert 'b' in storage assert storage['a'] == 42 assert storage['b'] == 73

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

 storage = Storage() key = arbitrary_key() value = arbitrary_value() storage[key] = value assert len(storage) == 1 assert key in storage assert storage[key] == value

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

 storage = arbitrary_storage() storage_copy = storage.copy() assert len(storage) == len(storage_copy) assert all(storage_copy[key] == storage[key] for key in storage) assert all(storage[key] == storage_copy[key] for key in storage_copy)

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

 storage = arbitrary_storage() backup = storage.copy() key = arbitrary_key() value = arbitrary_value() if key in storage: return storage[key] = value assert len(storage) == len(backup) + 1 assert key in storage assert storage[key] == value assert all(storage[key] == backup[key] for key in backup)

हम एक मनमाना भंडारण लेते हैं, और जांचते हैं कि हम वहां एक और तत्व जोड़ सकते हैं। तो जनरेटर दो तत्वों के साथ एक भंडार बना सकता है। और आप इसमें एक तत्व भी जोड़ सकते हैं। और इसी तरह (मैं गणितीय प्रेरण के रूप में ऐसी चीज को तुरंत याद करता हूं)। नतीजतन, तीन परीक्षण लिखे गए और जनरेटर यह मज़बूती से सत्यापित करना संभव बनाता है कि भंडारण के लिए विभिन्न तत्वों की एक मनमानी संख्या को जोड़ा जा सकता है। केवल तीन छोटे परीक्षण! यह मूल रूप से संपत्ति-आधारित परीक्षणों का संपूर्ण विचार है:

हम गुण पाते हैं
अलग-अलग डेटा के ढेर पर गुणों की जाँच करना
लाभ!

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

यह सब ठीक है और अच्छा है, लेकिन ...

संपत्ति-आधारित परीक्षण दृष्टिकोण की सभी अपील के साथ, समस्याओं का एक समूह है। इस भाग में मैं सबसे आम बनाने की कोशिश करूंगा। और उपयोगी गुणों को खोजने की वास्तविक जटिलता के साथ समस्याओं के अलावा (जो कि मैं अगले भाग में लौटूंगा), मेरी राय में शुरुआती लोगों के लिए सबसे बड़ी परेशानी अक्सर अच्छे कवरेज में एक गलत आत्मविश्वास होता है। दरअसल, हमने कई परीक्षण लिखे जो सैकड़ों परीक्षण मामलों को उत्पन्न करते हैं - क्या गलत हो सकता है? यदि आप पिछले भाग से उदाहरण देखते हैं, तो वास्तव में बहुत सारी चीजें हैं। शुरू करने के लिए, लिखित परीक्षण कोई गारंटी नहीं देते हैं कि Storage.copy () वास्तव में एक "गहरी" कॉपी करेगा, और न केवल पॉइंटर की प्रतिलिपि बनाएँ। एक और छेद - कोई सामान्य सत्यापन नहीं है कि स्टोरेज में कुंजी गलत वापस आ जाएगी यदि आप जिस कुंजी की तलाश कर रहे हैं वह स्टोर में नहीं है। और सूची बनती जाती है। ठीक है, मेरे पसंदीदा उदाहरणों में से एक है - मान लें कि हम एक प्रकार लिखते हैं, और किसी कारण से हम सोचते हैं कि एक परीक्षण जो तत्वों के क्रम की जांच करता है:

 input = arbitrary_list() output = sort(input) assert all(a <= b for a, b in zip(output, output[1:]))

और इसका ऐसा कार्यान्वयन पूरी तरह से गुजर जाएगा

 def sort(input): return [1, 2, 3]

मुझे उम्मीद है कि यहां नैतिक स्पष्ट है।

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

अब चौखटे के सवाल से, उनसे क्या उम्मीद की जाए और उनकी आवश्यकता क्यों है - आखिरकार, आपके हाथों से कोई भी एक चक्र में परीक्षण करने से मना नहीं करता है, जिससे अंदर एक यादृच्छिकता पैदा होती है और जीवन का आनंद मिलता है। वास्तव में, खुशी पहली परीक्षा में गिरने तक होगी, और यह स्थानीय स्तर पर अच्छा है, और कुछ सीआई में नहीं। सबसे पहले, चूंकि संपत्ति-आधारित परीक्षण यादृच्छिकीकृत हैं, आपको निश्चित रूप से एक गिराए गए मामले को मज़बूती से पुन: पेश करने का एक तरीका चाहिए, और कोई भी स्वाभिमानी ढांचा आपको ऐसा करने की अनुमति देता है। सबसे लोकप्रिय दृष्टिकोण कंसोल के लिए एक निश्चित बीज का उत्पादन करना है, जिसे आप परीक्षण धावक में मैन्युअल रूप से हथेली कर सकते हैं और मज़बूती से गिरा हुआ मामला (डिबगिंग के लिए सुविधाजनक) खेल सकते हैं, या "खराब" sids के साथ डिस्क पर एक कैश बना सकते हैं, जो परीक्षण शुरू होने पर स्वचालित रूप से जाँच की जाएगी। सीआई में दोहराव के साथ मदद करता है)। एक अन्य महत्वपूर्ण पहलू है डेटा मिनिफिकेशन (विदेशी स्रोतों में सिकुड़ना)। चूंकि डेटा यादृच्छिक रूप से उत्पन्न होता है, यानी 1000 तत्वों के कंटेनर के साथ गिरते हुए परीक्षण मामले पर पाने के लिए पूरी तरह से गैर-नकली मौका, जो अभी भी डिबग करने के लिए "खुशी" है। इसलिए, फेयैलीचैसी मामला खोजने के बाद अच्छी रूपरेखाएँ इनपुट डेटा के अधिक कॉम्पैक्ट सेट को खोजने की कोशिश करने के लिए कई आंकड़ें लागू करती हैं, जो फिर भी परीक्षण को क्रैश करना जारी रखेंगी। और अंत में - अक्सर परीक्षण कार्यक्षमता का आधा एक इनपुट डेटा जनरेटर होता है, इसलिए अंतर्निहित जनरेटर और प्राइमिटिव की उपस्थिति जो आपको सरल जनरेटर से अधिक जटिल बनाने की अनुमति देती है, बहुत मदद भी करती है।

सामयिक आलोचना भी है कि गुणों के आधार पर बहुत सारे तर्क परीक्षण हैं। हालांकि, यह आमतौर पर शैली में उदाहरणों के साथ होता है

 data = totally_arbitrary_data() perform_actions(sut, data) if is_category_a(data): assert property_a_holds(sut) else if is is_category_b(data): assert property_b_holds(sut)

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

 data = totally_arbitrary_data() assume(is_category_a(data)) perform_actions(sut, data) assert property_a_holds(sut)

और

 data = data_from_category_b() perform_actions(sut, data) assert property_b_holds(sut)

उपयोगी गुण, और उनके निवास स्थान

ठीक है, गुणों के आधार पर परीक्षण के लिए यह क्या उपयोगी है, यह स्पष्ट लगता है, मुख्य नुकसान को सुलझा लिया गया है ... हालांकि नहीं, मुख्य बात अभी भी स्पष्ट नहीं है - ये गुण कहां से आते हैं? आइए सर्च करने की कोशिश करते हैं।

कम से कम मत गिरो

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

परीक्षण का तांडव

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

 input = arbitrary_list() assert quick_sort(input) == bubble_sort(input)

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

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

आवश्यकताएँ और आक्रमणकारी

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

गुणों की जाँच के लिए उपयुक्त विभिन्न क्षेत्रों के उदाहरणों की एक छोटी सूची:

वर्ग फ़ील्ड में पहले से निर्दिष्ट मान होना चाहिए (गेटटर-सेटर)
भंडार पहले से रिकॉर्ड की गई वस्तु को पढ़ने में सक्षम होना चाहिए
रिपॉजिटरी में पहले से मौजूद किसी भी आइटम को जोड़ने से पहले से जोड़े गए आइटम पर कोई असर नहीं पड़ता है
कई शब्दकोशों में एक ही कुंजी के साथ कई अलग-अलग तत्वों को संग्रहीत नहीं किया जा सकता है
संतुलित पेड़ की ऊंचाई अधिक नहीं होनी चाहिए $K \ cdot लॉग (N)$ जहाँ $एन$ - दर्ज वस्तुओं की संख्या
क्रमबद्ध परिणाम आदेशित वस्तुओं की एक सूची है
base64 एन्कोडिंग परिणाम में केवल base64 वर्ण होना चाहिए
मार्ग-निर्माण एल्गोरिथ्म को अनुमेय आंदोलनों का एक क्रम वापस करना चाहिए जो बिंदु ए से बिंदु बी तक ले जाएगा
निर्मित आइसोलाइन के सभी बिंदुओं के लिए संतुष्ट होना चाहिए $f (x, y) = const$
इलेक्ट्रॉनिक हस्ताक्षर सत्यापन एल्गोरिथ्म सही होना चाहिए अगर हस्ताक्षर वास्तविक और गलत है तो
orthonormalization के परिणामस्वरूप, सभी वैक्टर में यूनिट की लंबाई और शून्य पारस्परिक स्केलर उत्पाद होने चाहिए
वेक्टर ट्रांसफर और रोटेशन ऑपरेशंस को इसकी लंबाई नहीं बदलनी चाहिए

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

प्रेरण और राज्य परीक्षण

कभी-कभी आपको किसी राज्य के साथ कुछ परीक्षण करने की आवश्यकता होती है। इस मामले में, सबसे आसान तरीका:

एक परीक्षण लिखें जो प्रारंभिक स्थिति की शुद्धता की जांच करता है (उदाहरण के लिए, जो कंटेनर अभी बनाया गया है वह खाली है)
एक जनरेटर लिखें जो यादृच्छिक संचालन के एक सेट का उपयोग करके सिस्टम को कुछ मनमाना स्थिति में लाएगा
एक प्रारंभिक स्थिति के रूप में जनरेटर के परिणाम का उपयोग करके सभी कार्यों के लिए परीक्षण लिखें

गणितीय प्रेरण के समान:

सिद्ध कथन १
कथन N + 1 को सिद्ध करें, मान लें कि कथन N सत्य है

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

पीछे-पीछे

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

 input = arbitrary_data() assert decode(encode(input)) == input

परीक्षण के लिए महान:

क्रमबद्धता-अक्रमांकन
एन्क्रिप्शन डिक्रिप्शन
एन्कोडिंग-dekodirvaniya
आधार मैट्रिक्स को चतुर्धातुक में बदलना और इसके विपरीत
प्रत्यक्ष और व्युत्क्रम समन्वय परिवर्तन
प्रत्यक्ष और उलटा फूरियर रूपांतरण

एक विशेष, लेकिन दिलचस्प मामला उलटा है:

 input = arbitrary_data() assert invert(invert(input)) == input

एक हड़ताली उदाहरण मैट्रिक्स का उलटा या ट्रांसपोज़न है।

idempotency

कुछ संचालन बार-बार उपयोग के परिणाम को नहीं बदलते हैं। विशिष्ट उदाहरण:

छंटाई
वैक्टर और ठिकानों का कोई भी सामान्यीकरण
किसी मौजूदा वस्तु को किसी सेट या शब्दकोश में फिर से जोड़ना
ऑब्जेक्ट की कुछ संपत्ति में उसी डेटा को फिर से रिकॉर्ड करना
कैनोनिकल फॉर्म में डेटा डालना (JSON में स्थान उदाहरण के लिए एकीकृत शैली में ले जाते हैं)

यदि सामान्य डिकोड (इनपुट)) == इनपुट विधि समतुल्य इनपुट डेटा (फिर से, कुछ JSON में अतिरिक्त रिक्त स्थान) के लिए अलग-अलग संभावित अभ्यावेदन के कारण उपयुक्त नहीं है, तो क्रमिक-निरूपण का परीक्षण करने के लिए उपयोग किया जा सकता है।

 def normalize(input): return decode(encode(input)) input = arbitrary_data() assert normalize(normalize(input)) == normalize(input)

अलग-अलग तरीके, एक परिणाम

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

 a = arbitrary_value() b = arbitrary_value() assert a + b == b + a

यह तुच्छ लग सकता है, लेकिन यह परीक्षण करने का एक शानदार तरीका है:

गैर-मानक प्रतिनिधित्व में संख्याओं का जोड़ और गुणा (bigint, rational, बस इतना ही)
परिमित क्षेत्रों में अण्डाकार वक्रों पर बिंदुओं का "जोड़" (हैलो, क्रिप्टोग्राफी!)
सेट का संघ (जिसके अंदर पूरी तरह से गैर-तुच्छ डेटा संरचनाएं हो सकती हैं)

इसके अलावा, शब्दकोश में तत्वों के जोड़ में एक ही गुण है:

 A = dict() A[key_a] = value_a A[key_b] = value_b B = dict() B[key_b] = value_b B[key_a] = value_a assert A == B

विकल्प अधिक जटिल है - लंबे समय से मैंने सोचा था कि इसे शब्दों में कैसे वर्णित किया जाए, लेकिन केवल एक गणितीय संकेतन दिमाग में आता है। सामान्य तौर पर, ऐसे परिवर्तन आम हैं

च

$च (x)$ जिसके लिए संपत्ति रखती है

$f (x + y) = f (x) \ cdot f (y)$ , और दोनों तर्क और फ़ंक्शन का परिणाम जरूरी नहीं कि केवल एक संख्या है, लेकिन संचालन

$+$ और

क ा ड

$\ _ काड$ - इन वस्तुओं पर बस कुछ बाइनरी संचालन। आप इसके साथ क्या परीक्षण कर सकते हैं:

इसके अलावा और सभी प्रकार की अजीब संख्या, वैक्टर, मेट्रिसेस, क्वाटरनियन ( $a \ cdot (x + y) = a \ cdot x + a \ cdot y$ )
विशेष रूप से सभी प्रकार के इंटीग्रल, डिफरेंशियल, कॉन्फोल्यूशन, डिजिटल फिल्टर, फूरियर ट्रांसफॉर्म इत्यादि, लीनियर ऑपरेटर्स $F [x + y] = F [x] + F [y]$ )
उदाहरण के लिए, विभिन्न अभ्यावेदन में समान वस्तुओं पर संचालन
- $M (q_a \ cdot q_b) = M (q_a) \ cdot M (q_b)$ जहाँ $q_a$ और $q_b$ एकल चतुर्भुज हैं, और $एम (क्यू)$ - एक चतुर्धातुक को एक समान आधार मैट्रिक्स में बदलने का कार्य
- $F [a \ circ b] = F [a] \ cdot F [b]$ जहाँ $एक$ और $ब$ सिग्नल हैं $\ _$ - आक्षेप $\ _ काड$ - गुणन, और $एफ$ - फूरियर रूपांतरण

थोड़ा और "साधारण" कार्य का एक उदाहरण - कुछ मुश्किल शब्दकोश विलय एल्गोरिथ्म का परीक्षण करने के लिए, आप इस तरह से कुछ कर सकते हैं:

 a = arbitrary_list_of_kv_pairs() b = arbitrary_list_of_kv_pairs() result = as_dict(a) result.merge(as_dict(b)) assert result == as_dict(a + b)

एक निष्कर्ष के बजाय

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

अजगर: परिकल्पना
जंग: प्रचंड
स्केला : स्कैलचेक
C ++: Rapidcheck
जावास्क्रिप्ट: FastCheck
गो: जठर

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

चिंता को कैसे रोकें और संपत्ति-आधारित परीक्षण लिखना शुरू करें