अपाचे Hadoop कोड गुणवत्ता: उत्पादन वी.एस. टेस्ट

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

परियोजना के बारे में

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

Hadoop में चार मुख्य मॉड्यूल होते हैं, उनमें से प्रत्येक एक बड़े डेटा एनालिटिक्स सिस्टम के लिए आवश्यक विशिष्ट कार्य करता है:

• Hadoop आम
• MapReduce
• Hadoop वितरित फ़ाइल सिस्टम
• यार्न

वैसे भी, इंटरनेट पर इसके बारे में बहुत सारी सामग्रियां हैं।

जाँच के बारे में

जैसा कि प्रलेखन में दिखाया गया है, पीवीएस-स्टूडियो को परियोजना में विभिन्न तरीकों से एकीकृत किया जा सकता है:

• मावेन प्लगइन का उपयोग करना;
• ग्रेडल प्लगइन का उपयोग करना;
• ग्रेडेल इंटेलीज आईडिया का उपयोग करना;
• सीधे विश्लेषक का उपयोग कर।

Hadoop मावेन बिल्ड सिस्टम पर आधारित है, इसलिए, चेक के साथ कोई बाधा नहीं थी।

जब मैंने दस्तावेज़ से स्क्रिप्ट को एकीकृत किया और pom.xml फ़ाइलों में से एक को संपादित किया (निर्भरता में मॉड्यूल थे जो उपलब्ध नहीं थे), विश्लेषण शुरू हुआ!

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

बाद में मैंने सबसे पेचीदा चेतावनियों का चयन किया, मैंने उन्हें निम्न समूहों द्वारा विभाजित किया: उत्पादन, परीक्षण और चार मुख्य हडोप मॉड्यूल। और अब मुझे आपका ध्यान विश्लेषक चेतावनी की समीक्षा की पेशकश करने में खुशी हो रही है।

उत्पादन कोड

Hadoop आम

V6033 समान कुंजी 'KDC_BIND_ADDRESS' के साथ एक आइटम पहले ही जोड़ा जा चुका है। MiniKdc.java (163), MiniKdc.java (162)

public class MiniKdc { .... private static final Set<String> PROPERTIES = new HashSet<String>(); .... static { PROPERTIES.add(ORG_NAME); PROPERTIES.add(ORG_DOMAIN); PROPERTIES.add(KDC_BIND_ADDRESS); PROPERTIES.add(KDC_BIND_ADDRESS); // <= PROPERTIES.add(KDC_PORT); PROPERTIES.add(INSTANCE); .... } .... } 

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

MapReduce

V6072 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'लोकलफेयर' के बजाय 'लोकलफाइल्स' चर का उपयोग किया जाना चाहिए। LocalDistributedCacheManager.java (183), LocalDistributedCacheManager.java (178), LocalDistributedCacheManager.java (176), LocalDistributedCacheManager.java (181)

 public synchronized void setup(JobConf conf, JobID jobId) throws IOException { .... // Update the configuration object with localized data. if (!localArchives.isEmpty()) { conf.set(MRJobConfig.CACHE_LOCALARCHIVES, StringUtils .arrayToString(localArchives.toArray(new String[localArchives // <= .size()]))); } if (!localFiles.isEmpty()) { conf.set(MRJobConfig.CACHE_LOCALFILES, StringUtils .arrayToString(localFiles.toArray(new String[localArchives // <= .size()]))); } .... } 

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

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

यह गफ़ निम्न परिदृश्य को जन्म दे सकता है:

• मान लीजिए, हमारे पास स्थानीय आकृतियाँ (आकार = 4) और स्थानीयकृत (आकार = 2) हैं;
• एरे लोकलफाइल्स.टोअराइरे (नया स्ट्रिंग [localArchives.size ()]) बनाते समय , अंतिम 2 तत्व शून्य होंगे (["pathToFile1", "pathToFile2", null, null]);
• फिर org.apache.hadoop.util.StringUtils.arrayToString हमारे एरे का स्ट्रिंग प्रतिनिधित्व लौटाएगा, जिसमें अंतिम फाइलों के नाम "null" ("pathToFile1, pathToFile2, null, null" ) के रूप में प्रस्तुत किए जाएंगे;
• यह सब आगे पारित किया जाएगा और भगवान ही जानता है कि इस तरह के मामलों के लिए किस तरह की जाँचें =) हैं।

V6007 अभिव्यक्ति 'बच्चों। आकार ()> 0' हमेशा सच है। कतार.जावा (347)

 boolean isHierarchySameAs(Queue newState) { .... if (children == null || children.size() == 0) { .... } else if(children.size() > 0) { .... } .... } 

इस तथ्य के कारण कि तत्वों की संख्या 0 के लिए अलग से जाँच की जाती है, आगे के बच्चों की जांच करें। आकार ()> 0 हमेशा सच होगा।

HDFS

V6001 समान उप-अभिव्यक्तियाँ हैं 'this.bucketSize' बाईं ओर और '%' ऑपरेटर के दाईं ओर। रोलिंग विंदो। जावा (79)

  RollingWindow(int windowLenMs, int numBuckets) { buckets = new Bucket[numBuckets]; for (int i = 0; i < numBuckets; i++) { buckets[i] = new Bucket(); } this.windowLenMs = windowLenMs; this.bucketSize = windowLenMs / numBuckets; if (this.bucketSize % bucketSize != 0) { // <= throw new IllegalArgumentException( "The bucket size in the rolling window is not integer: windowLenMs= " + windowLenMs + " numBuckets= " + numBuckets); } } 

यहां दोष यह है कि चर स्वयं से विभाजित है। नतीजतन, बहुलता की जांच हमेशा सफल होगी और गलत इनपुट ( windowLenMs , numBuckets ) प्राप्त करने के मामले में, अपवाद कभी नहीं फेंका जाएगा।

यार्न

V6067 दो या दो से अधिक केस-शाखाएँ एक ही क्रिया करते हैं। टाइमलाइनइंटरिटी वी 2 कनेक्टोर्टर.जावा (386), टाइमलाइनइंटीवीसीऑनक्वर्टर.जवा (386)

  public static ApplicationReport convertToApplicationReport(TimelineEntity entity) { .... if (metrics != null) { long vcoreSeconds = 0; long memorySeconds = 0; long preemptedVcoreSeconds = 0; long preemptedMemorySeconds = 0; for (TimelineMetric metric : metrics) { switch (metric.getId()) { case ApplicationMetricsConstants.APP_CPU_METRICS: vcoreSeconds = getAverageValue(metric.getValues().values()); break; case ApplicationMetricsConstants.APP_MEM_METRICS: memorySeconds = ....; break; case ApplicationMetricsConstants.APP_MEM_PREEMPT_METRICS: preemptedVcoreSeconds = ....; // <= break; case ApplicationMetricsConstants.APP_CPU_PREEMPT_METRICS: preemptedVcoreSeconds = ....; // <= break; default: // Should not happen.. break; } } .... } .... } 

दो मामले शाखाओं में समान कोड के टुकड़े। यह सब जगह है! प्रचलित मामलों में, यह एक वास्तविक त्रुटि नहीं है, बल्कि स्विच के बारे में सोचने का सिर्फ एक कारण है। लेकिन केस के लिए नहीं। बार-बार कोड के टुकड़े, वैरिएबल प्रीमेप्टेड VcoreSeconds के वैल्यू को सेट करते हैं। यदि आप सभी चर और स्थिरांक के नामों को करीब से देखते हैं, तो आप शायद यह निष्कर्ष निकालेंगे कि यदि मेट्रिक.गेटआईडीडी () == APP_MEM_PREEMPT_METRICS के लिए मान पूर्व निर्धारित किए गए होना चाहिए। MemorySeconds वैरिएबल, preemptedVcoreSeconds के लिए नहीं। इस संबंध में, 'स्विच' ऑपरेटर के बाद, preemptedMemorySeconds हमेशा 0 रहेगा, जबकि preemptedVcoreSeconds का मान गलत हो सकता है।

V6046 गलत प्रारूप। विभिन्न प्रकार के प्रारूप आइटम अपेक्षित हैं। तर्क का उपयोग नहीं किया: 2. AbstractSchedulerPlanFollower.java (186)

 @Override public synchronized void synchronizePlan(Plan plan, boolean shouldReplan) { .... try { setQueueEntitlement(planQueueName, ....); } catch (YarnException e) { LOG.warn("Exception while trying to size reservation for plan: {}", currResId, planQueueName, e); } .... } 

लॉग करते समय planQueueName चर का उपयोग नहीं किया जाता है। इस स्थिति में, या तो बहुत अधिक कॉपी किया जाता है या प्रारूप स्ट्रिंग समाप्त नहीं होता है। लेकिन मैं अभी भी अच्छे पुराने कॉपी-पेस्ट को दोष देता हूं, जो कुछ मामलों में खुद को पैर में गोली मारने के लिए बहुत अच्छा है।

टेस्ट कोड

Hadoop आम

V6072 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'allSecretsB' के बजाय 'allSecretsB' वैरिएबल का उपयोग किया जाना चाहिए। TestZKSignerSecretProvider.java (316), TestZKSignerSecretProvider.java (309), TestZKSignerSecretProvider.java (306), TestZKSignerSecretProvider.java (313)

 public void testMultiple(int order) throws Exception { .... currentSecretA = secretProviderA.getCurrentSecret(); allSecretsA = secretProviderA.getAllSecrets(); Assert.assertArrayEquals(secretA2, currentSecretA); Assert.assertEquals(2, allSecretsA.length); // <= Assert.assertArrayEquals(secretA2, allSecretsA[0]); Assert.assertArrayEquals(secretA1, allSecretsA[1]); currentSecretB = secretProviderB.getCurrentSecret(); allSecretsB = secretProviderB.getAllSecrets(); Assert.assertArrayEquals(secretA2, currentSecretB); Assert.assertEquals(2, allSecretsA.length); // <= Assert.assertArrayEquals(secretA2, allSecretsB[0]); Assert.assertArrayEquals(secretA1, allSecretsB[1]); .... } 

और फिर से V6072। चर allSecretsA और allSecretsB को बारीकी से देखें ।

V6043 'ऑपरेटर' के लिए निरीक्षण करने पर विचार करें। इटरेटर के प्रारंभिक और अंतिम मूल्य समान हैं। TestTFile.java (235)

 private int readPrepWithUnknownLength(Scanner scanner, int start, int n) throws IOException { for (int i = start; i < start; i++) { String key = String.format(localFormatter, i); byte[] read = readKey(scanner); assertTrue("keys not equal", Arrays.equals(key.getBytes(), read)); try { read = readValue(scanner); assertTrue(false); } catch (IOException ie) { // should have thrown exception } String value = "value" + key; read = readLongValue(scanner, value.getBytes().length); assertTrue("values nto equal", Arrays.equals(read, value.getBytes())); scanner.advance(); } return (start + n); } 

एक परीक्षण जो हमेशा हरा होता है? =)। लूप का एक हिस्सा, जो स्वयं परीक्षण का एक हिस्सा है, कभी भी निष्पादित नहीं होगा। यह इस तथ्य के कारण है कि प्रारंभिक और अंतिम काउंटर मान कथन के लिए समान हैं। नतीजतन, ऐसी स्थिति i <start तुरंत झूठी हो जाएगी, जिससे इस तरह का व्यवहार होता है। मैं परीक्षण फ़ाइल के माध्यम से भाग गया और इस निष्कर्ष पर पहुंच गया कि वास्तव में मैं <(प्रारंभ + n) को लूप स्थिति में लिखा जाना था।

MapReduce

V6007 अभिव्यक्ति 'बाइटअम <0' हमेशा झूठी होती है। DataWriter.java (322)

 GenerateOutput writeSegment(long byteAm, OutputStream out) throws IOException { long headerLen = getHeaderLength(); if (byteAm < headerLen) { // not enough bytes to write even the header return new GenerateOutput(0, 0); } // adjust for header length byteAm -= headerLen; if (byteAm < 0) { // <= byteAm = 0; } .... } 

हालत बाइटएएम <0 हमेशा गलत है। इसका पता लगाने के लिए, आइए एक और झलक के ऊपर कोड दें। यदि परीक्षण निष्पादन ऑपरेशन बाइट तक पहुँचता है - = शीर्ष लेख , तो इसका अर्थ है कि बाइटअम> = शीर्ष लेख। यहाँ से, घटाव के बाद, बाइटए वैल्यूएविल कभी भी नकारात्मक नहीं होगा। यही हमें साबित करना था।

HDFS

V6072 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'normalFile' के बजाय 'normalFile' चर का उपयोग किया जाना चाहिए। TestWebHDFS.java (625), TestWebHDFS.java (615), TestWebHDFS.java (614), TestWebHDFS.java (624)

 public void testWebHdfsErasureCodingFiles() throws Exception { .... final Path normalDir = new Path("/dir"); dfs.mkdirs(normalDir); final Path normalFile = new Path(normalDir, "file.log"); .... // logic block #1 FileStatus expectedNormalDirStatus = dfs.getFileStatus(normalDir); FileStatus actualNormalDirStatus = webHdfs.getFileStatus(normalDir); // <= Assert.assertEquals(expectedNormalDirStatus.isErasureCoded(), actualNormalDirStatus.isErasureCoded()); ContractTestUtils.assertNotErasureCoded(dfs, normalDir); assertTrue(normalDir + " should have erasure coding unset in " + ....); // logic block #2 FileStatus expectedNormalFileStatus = dfs.getFileStatus(normalFile); FileStatus actualNormalFileStatus = webHdfs.getFileStatus(normalDir); // <= Assert.assertEquals(expectedNormalFileStatus.isErasureCoded(), actualNormalFileStatus.isErasureCoded()); ContractTestUtils.assertNotErasureCoded(dfs, normalFile); assertTrue( normalFile + " should have erasure coding unset in " + ....); } 

मानो या न मानो, यह फिर से V6072 है! बस चर का पालन करें normalDir और normalFile।

V6027 चर को एक ही फ़ंक्शन के लिए कॉल के माध्यम से आरंभीकृत किया जाता है। यह शायद एक त्रुटि या अन-अनुकूलित कोड है। TestDFSAdmin.java (883), TestDFSAdmin.java (879)

 private void verifyNodesAndCorruptBlocks( final int numDn, final int numLiveDn, final int numCorruptBlocks, final int numCorruptECBlockGroups, final DFSClient client, final Long highestPriorityLowRedundancyReplicatedBlocks, final Long highestPriorityLowRedundancyECBlocks) throws IOException { /* init vars */ .... final String expectedCorruptedECBlockGroupsStr = String.format( "Block groups with corrupt internal blocks: %d", numCorruptECBlockGroups); final String highestPriorityLowRedundancyReplicatedBlocksStr = String.format( "\tLow redundancy blocks with highest priority " + "to recover: %d", highestPriorityLowRedundancyReplicatedBlocks); final String highestPriorityLowRedundancyECBlocksStr = String.format( "\tLow redundancy blocks with highest priority " + "to recover: %d", highestPriorityLowRedundancyReplicatedBlocks); .... } 

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

V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। TestReplaceDatanodeFailureReplication.java (222)

 private void verifyFileContent(...., SlowWriter[] slowwriters) throws IOException { LOG.info("Verify the file"); for (int i = 0; i < slowwriters.length; i++) { LOG.info(slowwriters[i].filepath + ....); FSDataInputStream in = null; try { in = fs.open(slowwriters[i].filepath); for (int j = 0, x;; j++) { x = in.read(); if ((x) != -1) { Assert.assertEquals(j, x); } else { return; } } } finally { IOUtils.closeStream(in); } } } 

विश्लेषक शिकायत करता है कि लूप में i ++ काउंटर को बदला नहीं जा सकता है। जिसका अर्थ है कि (int i = 0; i <slowwriters.length; i ++) {....} लूप के लिए एक से अधिक पुनरावृत्ति निष्पादित नहीं होगी। आइए जानें इसका कारण। इसलिए, पहले पुनरावृत्ति में, हम थ्रेड को उस फ़ाइल से लिंक करते हैं जो आगे के पढ़ने के लिए धीमे लिखने वाले [0] से मेल खाती है। अगला, हम फ़ाइल सामग्री को लूप के माध्यम से पढ़ते हैं (int j = 0, x ;; j ++):

• यदि हम कुछ प्रासंगिक पढ़ते हैं, तो हम पढ़े हुए बाइट की तुलना जे काउंटर के वर्तमान मूल्य के साथ करते हैं, हालांकि (यदि जाँच सफल नहीं होती है, तो हम परीक्षण से बाहर हो जाते हैं);
• यदि फ़ाइल सफलतापूर्वक जाँची जाती है और हम फ़ाइल के अंत में पहुँच जाते हैं (हम -1 पढ़ते हैं), तो विधि बाहर निकल जाती है।

इसलिए, जो कुछ भी slowwriters [0] की जाँच के दौरान होता है, यह बाद के तत्वों की जाँच करने के लिए नहीं होगा। सबसे अधिक संभावना है, रिटर्न के बजाय ब्रेक का उपयोग करना होगा ।

यार्न

V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। TestNodeManager.java (176)

 @Test public void testCreationOfNodeLabelsProviderService() throws InterruptedException { try { .... } catch (Exception e) { Assert.fail("Exception caught"); e.printStackTrace(); } } 

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

कई समान टुकड़े पाए गए हैं:

• V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। TestResourceTrackerService.java (928)
• V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। TestResourceTrackerService.java (737)
• V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। TestResourceTrackerService.java (685)
• ....

V6072 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'publicCache' चर का उपयोग 'usercache' के बजाय किया जाना चाहिए। TestResourceLocalizationService.java (315), TestResourceLocalizationService.java (309), TestResourceLocalizationService.java (307), TestResourceLocalizationService.java (313)

 @Test public void testDirectoryCleanupOnNewlyCreatedStateStore() throws IOException, URISyntaxException { .... // verify directory creation for (Path p : localDirs) { p = new Path((new URI(p.toString())).getPath()); // logic block #1 Path usercache = new Path(p, ContainerLocalizer.USERCACHE); verify(spylfs).rename(eq(usercache), any(Path.class), any()); // <= verify(spylfs).mkdir(eq(usercache), ....); // logic block #2 Path publicCache = new Path(p, ContainerLocalizer.FILECACHE); verify(spylfs).rename(eq(usercache), any(Path.class), any()); // <= verify(spylfs).mkdir(eq(publicCache), ....); .... } .... } 

और अंत में, V6072 फिर से =)। संदिग्ध टुकड़ा देखने के लिए चर: उपयोगकर्ता कैश और सार्वजनिक कैश ।

निष्कर्ष

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

इस बार, Apache Hadoop कोड आधार की जाँच करते समय, उत्पादन और परीक्षण दोनों में स्थैतिक विश्लेषण की अत्यधिक आवश्यकता थी जो विकास में भी महत्वपूर्ण भूमिका निभाते हैं।

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