सबसे आसान और सार परीक्षण

ज्वाइन करने के बजाय

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

यूनिट परीक्षणों के बारे में थोड़ा सा

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

• प्रोग्राम कोड में त्रुटियों का पता लगाना
• प्रोग्रामर विश्वास दिलाते हैं कि उनका कोड काम करता है
• पिछले पैराग्राफ से कोरोलरी: प्रोग्राम को सुरक्षित रूप से संशोधित करने की क्षमता
• टेस्ट - एक प्रकार का प्रलेखन जो सिस्टम के व्यवहार का सही ढंग से वर्णन करता है

एक मायने में, परीक्षण कार्यक्रम की संरचना को दोहराते हैं। क्या परीक्षणों के निर्माण के कार्यक्रम के सिद्धांत लागू होते हैं? मेरा मानना ​​है कि हां - यह एक ही कार्यक्रम है, यद्यपि दूसरे का परीक्षण।

समस्या का वर्णन

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

class SerializerChecker(TestCase): model = None serializer = None def test_fields_creation(self): props = TestObjectFactory.get_properties_for_model(self.model) obj = TestObjectFactory.create_test_object_for_model(self.model) serialized = self.serializer(obj) self.check_dict(serialized.data, props) 

मुझे लगता है, यहां तक ​​कि TestObjectFactory और check_dict पद्धति के कार्यान्वयन को जानने के बिना, यह स्पष्ट है कि प्रॉप्स एक वस्तु के लिए गुणों का शब्दकोश है, obj एक ऐसी वस्तु है जिसके लिए हम सीरियलाइज़र की जाँच कर रहे हैं। check_dict एक मैच के लिए पुनरावर्ती रूप से शब्दकोशों की जांच करता है। मुझे लगता है कि यूनिटेस्ट से परिचित कई लोग तुरंत कहेंगे कि यह परीक्षण मेरे सार की परिभाषा को पूरा नहीं करता है। क्यों? क्योंकि इस वर्ग से test_fields_creation पद्धति निष्पादित होगी, जिसकी हमें बिल्कुल आवश्यकता नहीं है। कुछ सूचनाओं की खोज के बाद, मैं इस नतीजे पर पहुंचा कि सबसे पर्याप्त विकल्प टेस्टकैसेज़ से SerializerChecker को विरासत में नहीं देना है, लेकिन वारिस को किसी भी तरह से लागू करना है:

 class VehicleSerializerTest(SerializerChecker, RecursiveTestCase): model = Vehicle serializer = VehicleSerialize 

RecursiveTestCase TestCase का एक वंशज है जो check_dict पद्धति को लागू करता है।

यह समाधान एक साथ कई पदों से बदसूरत है:

• SerializerChecker वर्ग में, हमें यह जानना होगा कि बच्चे को TestCase से वारिस होना चाहिए। यह निर्भरता इस कोड से अपरिचित लोगों के लिए समस्या पैदा कर सकती है।
• विकास का वातावरण हठपूर्वक मानता है कि मैं गलत हूं, क्योंकि SerializerChecker के पास check_dict पद्धति नहीं है

त्रुटि है कि विकास पर्यावरण फेंकता है

ऐसा लगता है कि आप check_dict के लिए एक स्टब जोड़ सकते हैं और सभी समस्याओं का समाधान किया गया है:

 class SerializerChecker: model = None serializer = None def check_dict(self, data, props): raise NotImplementedError def test_fields_creation(self): props = TestObjectFactory.get_properties_for_model(self.model) obj = TestObjectFactory.create_test_object_for_model(self.model) serialized = self.serializer(obj) self.check_dict(serialized.data, props) 

लेकिन यह समस्या का पूर्ण समाधान नहीं है:

• हमने वास्तव में, एक इंटरफ़ेस बनाया है जो इस वर्ग का वंशज नहीं है, लेकिन RecursiveTestCase, जो वास्तुकला के लिए उचित प्रश्न बनाता है।
• TestCase में कई दावे * तरीके हैं। क्या हमें वास्तव में प्रत्येक उपयोग के लिए एक स्टब लिखने की आवश्यकता है? अभी भी एक अच्छा समाधान की तरह लगता है?

संक्षेप में देना

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