पठनीय परीक्षण

प्रविष्टि

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

यूनिट। यह क्या है

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

एक इकाई कोड का एक टुकड़ा है जो कुछ इनपुट डेटा के साथ दिए गए वातावरण में कुछ आउटपुट प्रदान करता है।

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

उदाहरण

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

खाली वातावरण

यह संरचनात्मक अपघटन की शैली में लिखी गई इकाइयों के लिए सबसे आम विन्यास है। एक फ़ंक्शन जो तर्कों को लेता है और परिणाम देता है, एक इकाई का एक उदाहरण है जिसमें इनपुट के रूप में बहुत सारे तर्क हैं और परिणामस्वरूप आउटपुट । इनपुट मापदंडों के साथ परिणाम का कनेक्शन फ़ंक्शन का सार है। उदाहरण के लिए, फ़ंक्शन y = sin (x) अंतराल पर सभी वास्तविक संख्याओं के सेट की मैपिंग है [-1,1]। प्रत्येक इनपुट x के लिए, y को विशिष्ट रूप से परिभाषित किया गया है, और पाप (x) की जिम्मेदारी इस विशिष्टता को सुनिश्चित करना है। पाप (x) किसी भी उपयोगकर्ता के लिए किसी भी वातावरण में, वर्ष के किसी भी समय इन x को इन y में मैप करेगा। उसे पर्यावरण में कोई दिलचस्पी नहीं है।

खाली उत्पादन

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

खाली इनपुट

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

शून्य च ()

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

स्थिति और इकाइयाँ

उपरोक्त उदाहरणों और परिभाषाओं के प्रकाश में, आइए फ़ंक्शन void std :: list :: remove (const T & elem) को देखें। मान लीजिए कि एलएम इनपुट है। लेकिन पर्यावरण और आउटपुट का क्या? कोई आउटपुट नहीं है - शून्य फ़ंक्शन। और फिर पर्यावरण क्या है? औपचारिक रूप से - स्मृति। लेकिन स्मृति एक सूची की तुलना में निचले स्तर की इकाई है। आखिरकार, कोई भी यह तर्क नहीं देगा कि "सूची से हटाने से कुछ पेचीदा योजना के अनुसार मेमोरी खाली हो जाती है।" यदि आप यह निर्धारित करने का प्रयास करते हैं कि "सूची से हटाने" का अर्थ क्या है (इसका अर्थ क्या है), तो यह कुछ इस तरह से ध्वनि करेगा: "सूची से एक तत्व को हटाने से सूची की स्थिति में बदलाव होता है, ताकि सूची से इस तत्व को प्राप्त करना संभव न हो"। तो, सूची से विलोपन के शब्दार्थ की परिभाषा सूची इंटरफ़ेस से दूसरे ऑपरेशन का उपयोग करके, स्वयं को हटाने के रूप में अमूर्तता के समान स्तर पर की जाती है। इस प्रकार, सूची :: निकालें फ़ंक्शन स्वयं एक इकाई नहीं है । यह निर्धारित करना (और सत्यापित करना) हर चीज से अलगाव में स्वयं को निर्धारित करना असंभव है। सूची केवल इस पर संचालन की समग्रता में समझ में आता है। सूची इकाई है । इसके लिए इनपुट बहुत सारे जोड़े (कमांड, कमांड_आर्गुमेंट्स), और एक जोड़ी (क्वेरी, क्वेरी_फॉल्ट्स) का आउटपुट है। वैसे, यह एसटीएल डिज़ाइन सीक्यूएस (कमांड क्वेरी पृथक्करण) सिद्धांत का अनुपालन करता है, जिसमें राज्य बदलने और इसे वापस करने के तरीके अलग-अलग होते हैं (यह सुरक्षा के लिए अन्य चीजों के साथ, यह किया गया था)। सामान्य मामले में, हालांकि, एक वर्ग में बहुत अधिक आउटपुट होता है जो इसके कुछ संचालन के परिणामों का भी उपयोग कर सकता है जिनके पास इनपुट है। बुरा, लेकिन संभव है। वैसे, सवाल यह है कि पर्यावरण के बारे में क्या? क्या std :: सूची भी पर्यावरण अज्ञेयवादी है? नहीं! आप इसके लिए आवंटन प्रस्तुत कर सकते हैं! मेमोरी के साथ काम करना लोकेटर के माध्यम से एक सूची है। सूची ने स्पष्ट रूप से पर्यावरण पर निर्भरता की घोषणा की। शाबाश!

पढ़ने योग्य परीक्षण

ऐसा लगता है, यूनिट परीक्षणों के सिद्धांत के साथ क्या करना है जब उन्होंने परीक्षणों की पठनीयता के बारे में बात करने का वादा किया था? उत्तर सरल है:

यूनिट टेस्ट पठनीय है जिसमें यूनिट को निर्धारित करने में शामिल सभी चार घटक होते हैं: यूनिट , इनपुट और आउटपुट डेटा, और पर्यावरण स्पष्ट हैं।

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

टेस्ट एनाटॉमी

विशिष्ट सिफारिशें देने से पहले, हम कुछ परिभाषाएँ बनाते हैं ताकि कोई अस्पष्टता न हो। तो, gtest इकाई परीक्षण ढांचे का उपयोग करके लिखा गया एक विशिष्ट परीक्षण इस तरह दिखता है:

TEST(Subject, Assertion) { // Body } 

या तो:

 TEST_F(Subject, Assertion) { // Body } 

नियम

इकाई स्पष्ट

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

खराब:

 TEST(GetDiskSignature, ReadsFirstSector) TEST(SetDiskSignature, WritesToFirstSector) 

अच्छा:

 TEST(DiskSignature, ResidesOnFirstSector) 

परीक्षण की भविष्यवाणी

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

खराब:

 TEST(FileCache, IsInitializedCorrectly) 

अच्छा:

 TEST(FileCache, IsInitializedAsEmpty) 

शरीर में जोर से संस्थाओं का उपयोग करना

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

खराब:

 TEST_F(MRUCache, MovesLastAccessedItemToFront) { Items.Touch("http://facebook.com/"); Items.Touch("http://habrahabr.ru/"); EXPECT_EQ(0, Items.GetIndex("http://habrahabr.ru/")); } 

अच्छा:

 TEST_F(MRUCache, SetsIndexOfLastTouchedItemToZero) { MRUCache.Touch(Item("http://facebook.com/")); MRUCache.Touch(Item("http://habrahabr.ru/")); EXPECT_EQ(0, MRUCache.GetIndex(Item("http://habrahabr.ru/"))); } 

अच्छा:

 TEST_F(MRUCache, MovesLastAccessedItemToFront) { MRUCache.Access(Item("http://facebook.com/")); MRUCache.Access(Item("http://habrahabr.ru/")); EXPECT_EQ(Item("http://habrahabr.ru/"), MRUCache.Front()); } 

डेटा स्पष्टता का परीक्षण करें

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

खराब:

 const Common::String SomeUnixPath = GET_WCHAR("/var/log"); const int SomeUnixPathComponents = 2; ... TEST(UnixPath, ContainsSlashes) { EXPECT_EQ(SomeUnixPathComponents, Paths::Unix(SomeUnixPath).Components()); } 

अच्छा:

 Common::String Path(const char* value) { return GET_WCHAR(value); } ... TEST(UnixPath, ContainsSlashes) { EXPECT_EQ(2, Paths::Unix(Path("/var/log")).Components()); } 

टेस्ट डेटा फ्लो क्लियरनेस

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

खराब:

 MockFileSystem Files; void AddFile(std::string path, int size) { ON_CALL(Files, Get(path.c_str()).WillByDefault(Return(File(size))); } ... TEST(FileStatistics, SumsFileSizes) { AddFile("/bin/ls", 10); AddFile("/bin/bash", 20); EXPECT_EQ(30, GetStats(Files, "/bin").Size); } 

अच्छा:

 MockFileSystem Files; void AddFile(MockFileSystem& fs, std::string path, int size) { ON_CALL(fs, Get(path.c_str()).WillByDefault(Return(File(size))); } ... TEST(FileStatistics, SumsFileSizes) { AddFile(Files, "/bin/ls", 10); AddFile(Files, "/bin/bash", 20); EXPECT_EQ(10 + 20, GetStats(Files, "/bin").Size); } 

निष्कर्ष

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