व्हाइट बॉक्स परीक्षण

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

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

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

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

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

टेस्ट बेंच

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

 case class TestCase[A, B](label: String, input: A, expectedOutput: B) 

एक रन के परिणाम को TestCaseResult रूप में दर्शाया जा सकता है:

 case class TestCaseResult[A, B](testCase: TestCase[A, B], actualOutput: Try[B]) 

(हम संभावित अपवादों को पकड़ने की Try का उपयोग करके लॉन्च का परिणाम प्रस्तुत करते हैं।)

परीक्षण के तहत कार्यक्रम के माध्यम से सभी परीक्षण डेटा के रन को सरल बनाने के लिए, आप एक सहायक फ़ंक्शन का उपयोग कर सकते हैं जो प्रत्येक इनपुट के लिए प्रोग्राम को कॉल करेगा:

 def runTestCases[A, B](cases: Seq[TestCase[A, B])(f: A => B): Seq[TestCaseResult[A, B]] = cases .map{ testCase => TestCaseResult(testCase, Try{ f(testCase.input) } ) } .filter(r => r.actualOutput != Success(r.testCase.expectedOutput)) 

यह सहायक फ़ंक्शन समस्यात्मक डेटा और परिणाम लौटाएगा जो उम्मीद से अलग हैं।

सुविधा के लिए, आप परीक्षा परिणामों को प्रारूपित कर सकते हैं।

 def report(results: Seq[TestCaseResult[_, _]]): String = s"Failed ${results.length}:\n" + results .map(r => r.testCase.label + ": expected " + r.testCase.expectedOutput + ", but got " + r.actualOutput) .mkString("\n") 

और त्रुटियों के मामले में केवल एक रिपोर्ट प्रदर्शित करें:

 val testCases = Seq( TestCase("1", 0, 0) ) test("all test cases"){ val testBench = runTestCases(testCases) _ val results = testBench(f) assert(results.isEmpty, report(results)) } 

इनपुट तैयार करना

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

 val baseline = MyObject(...) //        val testCases = Seq( TestCase("baseline", baseline, ???), TestCase("baseline + (field1 = 123)", baseline.copy(field1 = "123"), ???) ) 

नेस्टेड अपरिवर्तनीय डेटा संरचनाओं के साथ काम करते समय, लेंस बहुत मदद करते हैं, उदाहरण के लिए, मोनोकल लाइब्रेरी से:

 val baseline = ??? val testObject1 = (field1 composeLens field2).set("123")(baseline) //    : val testObject1 = baseline.copy(field1 = baseline.field1.copy(field2 = "123")) 

लेंस आपको डेटा संरचनाओं के गहन रूप से नेस्टेड हिस्सों को "संशोधित" करने की अनुमति देते हैं: प्रत्येक लेंस एक संपत्ति के लिए एक गेट्टर और सेटर है। लेंस को लेंस का उत्पादन करने के लिए जोड़ा जा सकता है जो अगले स्तर पर "फोकस" करता है।

वर्तमान परिवर्तन के लिए DSL का उपयोग करना

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

 val testCases = Seq( TestCase("baseline", baseline, ???), TestCase("baseline + " + "(field1 = 123) + " + //  1-  "(field2 = 456) + " + // 2- "(field3 = 789)", // 3- baseline .copy(field1 = "123") // 1-  .copy(field2 = "456") // 2-  .copy(field3 = "789"), // 3-  ???) ) 

फिर हमें हमेशा पता चलेगा कि परीक्षण परीक्षण किस डेटा के लिए किया जाता है।

ताकि परिवर्तनों की पाठ्य सूची वास्तविक परिवर्तनों से अलग न हो, आपको "सत्य के एकल संस्करण" के सिद्धांत का पालन करना चाहिए। (यदि एक ही जानकारी की आवश्यकता है / कई बिंदुओं पर उपयोग की जाती है, तो अद्वितीय जानकारी का एक ही प्राथमिक स्रोत होना चाहिए, और आवश्यक परिवर्तन के साथ जानकारी को स्वचालित रूप से उपयोग के अन्य सभी बिंदुओं पर वितरित किया जाना चाहिए। यदि इस सिद्धांत का उल्लंघन किया गया है और जानकारी की मैन्युअल प्रतिलिपि अपरिहार्य है। । परीक्षण डाटा, हम एक देखते हैं, और परीक्षण डाटा के वर्णन में दूसरे शब्दों में विभिन्न बिंदुओं पर विसंगति संस्करण जानकारी -। एक और उदाहरण, एक परिवर्तन को कॉपी field2 = "456" और में यह एडजस्ट करने field3 = "789" हम Mauger गलती से वर्णन दूर करने के लिए भूल जाते हैं। नतीजतन, वर्णन केवल तीन में से दो परिवर्तन प्रतिबिंबित करेगा।)

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

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

परिवर्तन मॉडल को निम्नलिखित कार्यों को हल करने की अनुमति देनी चाहिए:

1. स्पॉन परिवर्तन मॉडल उदाहरण। (यह वास्तव में परिवर्तनों की एक विशिष्ट सूची बना रहा है।)
2. परिवर्तनों के एक शाब्दिक विवरण का गठन।
3. डोमेन ऑब्जेक्ट में परिवर्तन लागू करना।
4. मॉडल पर अनुकूलन रूपांतरण करना।

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

परिवर्तन मॉडल के उदाहरण बनाने के लिए एक और तरीका एक विशेष भाषा (डीएसएल) हो सकता है, जो विस्तार विधियों और सहायक ऑपरेटरों के सेट का उपयोग करके परिवर्तन मॉडल ऑब्जेक्ट बनाता है। खैर, सरलतम मामलों में, परिवर्तन मॉडल के उदाहरण सीधे निर्माणकर्ताओं के माध्यम से बनाए जा सकते हैं।

 val target: Entity[Target] // ,     val updateField1 = target \ field1 := "123" val updateField2 = target \ subobject \ field2 := "456" // ,   DSL: val updateField1 = SetProperty(PropertyAccess(target, Property(field1, typeTag[String])), LiftedString("123")) val updateField2 = SetProperty(PropertyAccess(PropertyAccess(target, Property(subobject, typeTag[SubObject])), Property(field2, typeTag[String])), LiftedString("456")) 

 def eval(expression: DslExpression, gamma: Map[String, Any]): Any = expression match { case LiftedString(str) => str case PropertyAccess(obj, prop) => Getter(prop)(gamma).get(obj) } def change[T] (expression: DslChangeExpression, gamma: Map[String, Any], target: T): T = expression match { case SetProperty(path, valueExpr) => val value = eval(valueExpr, gamma) Setter(path)(gamma).set(value)(target) } 

यह पूरी तरह से काम करता है, और वास्तव में आपको एक बार परिवर्तनों का वर्णन करने की अनुमति देता है, लेकिन धीरे-धीरे अधिक से अधिक जटिल परिवर्तनों का प्रतिनिधित्व करने की आवश्यकता है और परिवर्तनों का मॉडल कुछ हद तक बढ़ रहा है। उदाहरण के लिए, यदि आपको उसी ऑब्जेक्ट की अन्य संपत्ति के मूल्य का उपयोग करके एक संपत्ति को बदलने की आवश्यकता है (उदाहरण के लिए, field1 = field2 + 1 ), तो आपको डीएसएल स्तर पर चर का समर्थन करने की आवश्यकता है। और अगर किसी संपत्ति को बदलना नगण्य है, तो डीएसएल स्तर पर, अंकगणितीय अभिव्यक्तियों और कार्यों के लिए समर्थन की आवश्यकता होती है।

शाखा परीक्षण

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

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

 if (object.field1 == "123") A else B 

ऐसी स्थिति होने पर, हम दो परीक्षण मामले बना सकते हैं:

 val testCase1 = TestCase("A", field1.set("123")(baseline), /* result of A */) val testCase2 = TestCase("B", field1.set(/*  "123", , , */"123" + "1">)(baseline), /*result of B*/) 

(यदि किसी एक परिक्षण के परिदृश्य का निर्माण नहीं किया जा सकता है, तो हम मान सकते हैं कि मृत कोड का पता चला है, और इसी शाखा के साथ स्थिति को सुरक्षित रूप से हटाया जा सकता है।)

यदि किसी ऑब्जेक्ट के स्वतंत्र गुणों को कई शाखाओं में जांचा जाता है, तो संशोधित परीक्षण वस्तुओं का एक संपूर्ण सेट बनाना काफी सरल है जो पूरी तरह से संभव संयोजनों को कवर करता है।

 val change1: T => T = field1.set("123")(_) // val change1: T => T = _.copy(field1 = "123") val change2: T => T = field2.set("456") 

 val changes = change1 compose change2 

 val rawChangesList: Seq[T => T] = Seq(change1, change2) val allChanges: T => T = rawChangesList.foldLeft(identity)(_ compose _) 

 val tests: Seq[(String, T => T)] = IF("field1 == '123'") //  ,    THEN( field1.set("123"))( //  target \ field1 := "123" IF("field2 == '456') THEN(field2.set("456"))(TERMINATE) ELSE(field2.set("456" + "1"))(TERMINATE) ) ELSE( field1.set("123" + "1") )(TERMINATE) 

 val tests2: Seq[(String, T)] = tests.map(_.map_2(_(baseline))) 

परीक्षण डेटा की स्वचालित पीढ़ी

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

एकल शाखा वाले कोड के उदाहरण पर विचार करें:

 if(object.field1 == "123") A else B 

यह स्थिति field1 मान के सेट को दो समतुल्य वर्गों में विभाजित करती है: == "123" और != "123" । इस प्रकार, इनपुट डेटा के पूरे सेट को भी इस स्थिति के संबंध में दो समकक्ष वर्गों में विभाजित किया गया है - ClassCondition1IsTrue और ClassCondition1IsFalse । कवरेज की पूर्णता के दृष्टिकोण से, A और B दोनों को कवर करने के लिए इन दो वर्गों से कम से कम एक उदाहरण लेना हमारे लिए पर्याप्त है B पहली श्रेणी के लिए, हम एक अर्थ में, एक अनोखे तरीके से एक उदाहरण का निर्माण कर सकते हैं: एक यादृच्छिक वस्तु लें, लेकिन field1 को "123" बदल दें। इसके अलावा, ऑब्जेक्ट निश्चित रूप से समतुल्यता वर्ग ClassCondition1IsTrue में ClassCondition1IsTrue और गणना शाखा A साथ जाएगी A दूसरी श्रेणी के लिए और अधिक उदाहरण हैं। दूसरी श्रेणी के कुछ उदाहरण उत्पन्न करने का एक तरीका यह है कि मनमाने ढंग से इनपुट ऑब्जेक्ट उत्पन्न करें और field1 == "123" साथ उन लोगों को छोड़ दें। एक और तरीका: एक यादृच्छिक वस्तु लेने के लिए, लेकिन field1 को "123" + "*" में बदलें (संशोधन के लिए, आप नियंत्रण रेखा में किसी भी परिवर्तन का उपयोग यह सुनिश्चित करने के लिए कर सकते हैं कि नई लाइन नियंत्रण रेखा के बराबर नहीं है)।

ScalaCheck पुस्तकालय से Arbitrary और Gen रैंडम डेटा Arbitrary के रूप में काफी उपयुक्त हैं।

आवश्यक रूप से, हम if में उपयोग किए जाने वाले बूलियन फ़ंक्शन को कहते हैं । यही है, हम इनपुट ऑब्जेक्ट के सभी मान पाते हैं जिसके लिए यह बूलियन फ़ंक्शन true मान लेता true - ClassCondition1IsTrue , और इनपुट ऑब्जेक्ट के सभी मान जिसके लिए यह मान false - ClassCondition1IsFalse ।

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

कठिन प्रतिवर्ती कार्य

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

इस स्थिति में, आप इनपुट ऑब्जेक्ट के लिए एक अतिरिक्त पैरामीटर जोड़ सकते हैं जो फ़ंक्शन गणना के परिणाम का प्रतिनिधित्व करता है, फ़ंक्शन कॉल को इस पैरामीटर से कॉल करें, और कार्यात्मक कनेक्शन के उल्लंघन के बावजूद, इस पैरामीटर को अपडेट करें:

 if(sha(object.field1)=="a9403...") ... //     ==> if(object.sha_field1 == "a9403...") ... 

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

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

आश्रित स्थिति

, . , , , . , . (, , x > 0 , — x <= 1 . , — (-∞, 0] , (0, 1] , (1, +∞) , — .)

, , , true false . , , " " .

, , :

 if(x > 0) if(y > 0) if (y > x) 

( > 0 , — y > x .)
"", , , , , . , " " .
, "", ( y == x + 1 ), , .
"" ( y > x + 1 && y < x + 2 ), , .

, , - , "c " ( Symbolic Execution , ), . ( field1 = field1_initial_value ). , . :

 val a = field1 + 10 //    a = field_initial_value + 10 val b = a * 3 //    b = 3 * field_initial_value + 30 

— true false . . . उदाहरण के लिए

 if(a > 0) A else B //   A ,  field_initial_value + 10 > 0 //   B ,  field_initial_value + 10 <= 0 

, , , , . , (, , ).

. , , . , . , .

, . . , , . , , , . , , , , , ?

Y- ( " " , stackoverflow:What is a Y-combinator? (2- ) , habr: Y- 7 ). , . ( , , .) . , . , "" . Y- " " ( ).

( ). , . , . , . , , , TestCase '. , , ( throw Nothing bottom , ). .

, . . , , . , . , , . , , , , . , . , .

, , , , 100% . , , . हम्म। . , , , ? , , - .

:

1. .
2. ( ).
3. , .
4. , .

, , . -, , , , . -, , , ( , ), , , "" . / , .

निष्कर्ष

" " " ". , , , , . , .

, , , , . -, , ( ), . -, -, . DSL, , . -, , . -, , ( , , ). .

, , . , , - .

धन्यवाद

@mneychev .