कवर न हो पाने वाला कोड
(blog.npcode.com)इतने सरल Kotlin कोड में भी सभी branches को test करना लगभग असंभव जितना कठिन है। वजह यह है कि Kotlin इस कोड को bytecode में compile करते समय ऐसे branches बना देता है जिनका इरादा कोड लिखने वाले ने नहीं किया था.
when(answer) {
"yes" -> true
else -> false
}
Kotlin एक तरफ कोड लिखने वाले developer को कई सुविधाजनक features देता है, वहीं bytecode में compile होने पर इस तरह user को दिखाई न देने वाले branch statements भी बड़ी संख्या में बन जाते हैं। JVM platform पर सबसे व्यापक रूप से इस्तेमाल होने वाला test coverage tool jacoco, branch coverage की गणना bytecode के आधार पर करता है, इसलिए वह Kotlin भाषा का उपयोग करने वाले developer से ऐसे branches को भी cover करने की मांग कर सकता है जिन पर उनकी नजर ही न गई हो। इसलिए अगर कोई Kotlin developer test coverage 100% तक पहुंचाने की कोशिश करे, तो ऊपर जैसे मामलों में decompile करके देखना पड़ सकता है, और किस्मत और खराब हो तो decompile भी fail हो सकता है, जिससे सीधे bytecode देखकर यह जांचना पड़ सकता है कि वहां कौन-कौन से branches मौजूद हैं।
9 टिप्पणियां
कवर करना असंभव कोड
https://toss.im/slash-21/sessions/1-6
coverage tracking को 100% तक पहुँचाने के लिए code को मरोड़ना थोड़ा उल्टा लगता है।
कोड टेढ़ा-मेढ़ा नहीं था। बस इंसानी नज़रिए से एक और आसान तरीका मौजूद था।
रक्षा (weapon systems) क्षेत्र में DAPA के दिशानिर्देशों में code coverage 100% की मांग की जाती है.
वास्तव में 100% हासिल करना मुश्किल है, लेकिन मेरी जानकारी में इसके बदले जिन हिस्सों को cover नहीं किया जा सकता, उनके लिए एक-एक करके यह बताना पड़ता है कि उन्हें cover क्यों नहीं किया जा सकता।
पागलपन वाली 100% टेस्ट कवरेज सीट…
हाहाहा
enum / sealed / boolean की branching स्थितियों में अगर सही तरीके से हैंडल न किया जाए, तो Kotlin 1.6 में compiler warning देता था, और 1.7 से इसे error बनाने के लिए compiler बदल दिया गया है.
https://youtrack.jetbrains.com/issue/KT-47709
slash 21 में सामग्री बहुत अच्छी लगी haha
आह~ तो यह slash 21 में आया हुआ कंटेंट था... मैंने तो इसे पहली बार अपने एक परिचित के Twitter पर देखा था... देर से समझने के लिए माफ़ी...