जब सभी परीक्षण UP-TO-DATE हैं तो ग्रेड टेस्ट कैसे चलाया जाता है?

Question

मेरे पास मेरी ग्रेड स्क्रिप्ट है। जब मैं ग्रैड बिल्ड का निष्पादन करता हूं, तो सब कुछ काम कर रहा होता है और यह ज्यूनीट परीक्षण चलाता है।

उसके बाद जब मैं ग्रैडल टेस्ट चलाता हूं तो मुझे निम्नलिखित मिलते हैं:

C:\Users\..\..\Project>gradle test
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE

जब मैं प्रदर्शन gradle cleanकरता हूं , तो ग्रैडल निर्माण कार्य करता है, निश्चित रूप से ... मैं केवल परीक्षणों को रीसेट करने में सक्षम होना चाहता हूं, पूरे प्रोजेक्ट का निर्माण नहीं करना चाहिए: मुझे यह कैसे करना चाहिए?

Comments

यह अनावश्यक, दी गई जानकारी के आधार पर लगता है। यदि न तो एप्लिकेशन कोड और न ही परीक्षण कोड बदल गया है, तो आपको परीक्षणों को फिर से चलाने की आवश्यकता क्यों है?

— जोलता

@ जोलता मेरे कोड में कुछ परीक्षण 3-पार्टी इनपुट से संबंधित हैं, मैं अपने परीक्षण चला रहा हूं केवल यह सुनिश्चित करने के लिए कि मैंने कोड के अंदर कोई बग नहीं रखा है, यह भी जांचने के लिए कि क्या 3-पार्टी इनपुट पर कुछ परिवर्तन होता है कि मैं हो रहा हूँ

— USER22999299

क्षमा करें कि नाइट-पिकी है, लेकिन मुझे वास्तव में नहीं लगता कि यह इस बारे में सोचने का सही तरीका है: यदि आपके पास चर 3-पार्टी इनपुट है, तो इन आदानों को किसी तरह से नकली करने के लिए इससे निपटने का सही तरीका नहीं है? परीक्षण वास्तव में आपके द्वारा लिखे गए कोड के परीक्षण के बारे में होना चाहिए। यदि आप 3-पार्टी इनपुट पर भरोसा नहीं कर रहे हैं तो अस्वीकार्य होने के लिए आप गलत-सकारात्मक होने के खतरे में नहीं हैं? क्या आपके ऐप कोड के हिस्से के रूप में समस्या इनपुट के लिए रणनीति नहीं होनी चाहिए?

— माइक कृंतक

@mikerodent एक तृतीय पक्ष ऑनलाइन सेवा के खिलाफ अपने कोड का परीक्षण करने पर विचार करें। आप सेवा API में संभावित परिवर्तनों की निगरानी करना चाहते हैं ताकि वे तैनात फ़िक्स ASAP के साथ प्रतिक्रिया कर सकें। क्या सीआई परीक्षण करने का एक अच्छा तरीका नहीं है? मॉक का उपयोग करने से आपको केवल यह पता चलेगा कि आपके स्वयं के कोड में प्रतिगमन नहीं है, लेकिन निर्भरता में अभी भी परिवर्तन हो सकते हैं। वास्तविक सेवा का उपयोग यह इंगित करेगा कि आपका उत्पाद वास्तव में वर्तमान वातावरण में अपेक्षित संचालन कर सकता है।

— एलिस्ट

यह एकीकरण परीक्षण बिंदु से भी मान्य है जहां परीक्षण का बिंदु कोड के अन्य बिट्स के साथ अपने कोड के एकीकरण को मान्य करना है, जहां निर्भरता में मजाक करना उचित नहीं होगा

— 1800 सूचना

Answer 1

कमांड लाइन--rerun-tasks में ध्वज का उपयोग करना एक विकल्प होगा । यह सभी परीक्षण कार्य और उस पर निर्भर सभी कार्यों को फिर से शुरू करेगा।

यदि आप केवल परीक्षणों को पुन: निर्देशित करने में रुचि रखते हैं, तो परीक्षणों को निष्पादित करने से पहले परीक्षण के परिणामों को साफ करने के लिए एक और विकल्प होगा। यह cleanTestकार्य का उपयोग करके किया जा सकता है ।

कुछ पृष्ठभूमि - जावा प्लगइन प्रत्येक अन्य कार्यों के लिए एक स्वच्छ कार्य को परिभाषित करता है। प्रलेखन के अनुसार :

cleanTaskName - निर्दिष्ट कार्य द्वारा बनाई गई फ़ाइलों को हटाता है। cleanJar जार कार्य द्वारा बनाई गई JAR फ़ाइल को हटा देगा, और cleanTest परीक्षण कार्य द्वारा बनाए गए परीक्षा परिणाम को हटा देगा।

इसलिए, अपने परीक्षणों को फिर से चलाने के लिए आपको cleanTestकार्य को चलाने की आवश्यकता है, अर्थात:
gradle cleanTest test

Comments

gradle cleanTest testपरीक्षण फिर से नहीं करता है, यह उनके उत्पादन को साफ करता है, लेकिन testकार्य अभी भी कैश से परीक्षा परिणाम प्राप्त करेगा - देखें github.com/gradle/gradle/issues/9153

— dan.m 232:05 पर user2321368

ऊपर टिप्पणी सही है। लेकिन अगर आप उपयोग करते हैं --no-build-cache, तो यह उम्मीद के मुताबिक काम करेगा, जैसे gradle cleanTest test --no-build-cache।

— vRallev

Answer 2

अन्य विकल्प आपके build.gradle में निम्नलिखित जोड़ना होगा:

test.outputs.upToDateWhen {false}

Comments

मैंने funcTestकार्यात्मक परीक्षण चलाने के लिए बनाए गए कार्य के लिए इस तकनीक का उपयोग किया ।

— फैरसिकल

यह स्वीकृत उत्तर की तुलना में बहुत बेहतर दृष्टिकोण है, क्योंकि यह केवल वांछित कार्य पर लागू होगा। upToDateWhenइस तरह के सिस्टम गुण, वातावरण चर, परियोजना गुण, आदि के रूप में किसी भी "कोड पर ही आधारित" रास्ते में इस्तेमाल किया जा सकता

— mkobit

जैसा कि उत्तर stackoverflow.com/a/52484259/340175 उल्लेख करता है, एक उपयोगी ब्लॉग पोस्ट blog.gradle.org/stop-rerunning-tests है जो बताता है कि इस दृष्टिकोण को सामान्य दृष्टिकोण के रूप में अनुशंसित क्यों नहीं किया गया है। मैं इस बात से सहमत हूं कि यह उपयोगी हो सकता है और जो प्रश्न पूछता है उसे प्राप्त करता है।

— जूलियनहार्टी

हां, यह दिनांकित उत्तर है, जब मैंने लिखा था कि यह ग्रैडल 2.11 संस्करण में था और अभी प्रयोग करने योग्य है, लेकिन फिर भी इसमें कई खुरदरे किनारे थे, जिन्हें आज पॉलिश किया गया है।

— फ्रांटिसेक हार्टमैन

बहुत बढ़िया जवाब!!! एक पैरामीटर का उपयोग करके इसे पास किया गया gradle test -Prerun-tests:। कोड में build.gradle:if(project.hasProperty("rerun-tests")) { test.outputs.upToDateWhen {false} }

— AlikElzin-kilaka

Answer 3

gradle test --rerun-tasks

निर्दिष्ट करता है कि किसी भी कार्य अनुकूलन की अनदेखी की गई है।

स्रोत: https://gradle.org/docs/current/userguide/gradle_command_line.html

Comments

मुझे लगता है कि यह सभी आश्रित कार्यों को भी फिर से चलाएगा, जो कि अभिप्रेत व्यवहार नहीं है।

— एलिकएल्ज़िन-किलाका

Answer 4

यह हाल ही में ग्रैगल के ब्लॉग पोस्ट स्टॉप पर आपके परीक्षणों को पुन: निर्देशित करने वाला विषय था । लेखक का उपयोग कर एक उदाहरण दिखाता है outputs.upToDateWhen { false }और बताता है कि क्यों यह गलत है:

यह वास्तव में पुनर्मिलन को मजबूर नहीं करता है

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

इस स्निपेट के लिए भी यही सच है:

test.dependsOn cleanTest

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

यदि आप अब सोच रहे हैं "ठीक है, मैं कैश को भी निष्क्रिय कर दूंगा", मुझे आपको बताना चाहिए कि आपको क्यों नहीं करना चाहिए।

इसके बाद, लेखक यह बताता है कि कुछ परीक्षणों को फिर से करना क्यों समय की बर्बादी है:

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

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

task randomizedTest(type: Test) {
  systemProperty "random.testing.seed", new Random().nextInt()
}

---

task systemIntegrationTest(type: Test) {
  inputs.property "integration.date", LocalDate.now()
}

मैं पूरे ब्लॉग पोस्ट को पढ़ने की सलाह देता हूं।

Comments

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

— ब्रैंडन

Answer 5

यदि आप अपनी कमांड लाइन को संशोधित नहीं करना चाहते हैं, तो "build.gradle" फ़ाइल का उपयोग करके यहां एक समाधान है:

test {
    dependsOn 'cleanTest'
    //Your previous task details (if any)
}

और यहाँ आउटपुट है। अपने पिछले आउटपुट से 2 परिवर्तन देखें:

1) आउटपुट में एक नया 'क्लीनटेस्ट' कार्य दिखाई देता है।

2) 'टेस्ट' को हमेशा साफ किया जाता है (अर्थात कभी भी 'UP-TO-DATE') इसलिए इसे हर बार निष्पादित किया जाता है:

$ gradle build
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:findMainClass
:jar
:bootRepackage
:assemble
:cleanTest
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test
:check
:build

Comments

परीक्षण चलाने cleanTestसे पहले test, यह उनके आउटपुट को साफ करता है, लेकिन परीक्षण कार्य अभी भी कैश से परीक्षा परिणाम प्राप्त करेगा - देखें github.com/gradle/gradle/issues/9153

— dan.m था user232139

Answer 6

--rerun-tasks काम करता है, लेकिन अक्षम है क्योंकि यह सभी कार्यों को फिर से करता है।

cleanTest कैश के निर्माण के कारण अपने आप में पर्याप्त नहीं हो सकता है।

इसलिए, इसे पूरा करने का सबसे अच्छा तरीका है:

./gradlew --no-build-cache cleanTest test

Answer 7

इसके अलावा, जोड़ना --rerun-tasksवास्तव में बेमानी है। कभी नहीं होता। कब बनाएँ --no-rerun-tasksऔर --rerun-tasksकब डिफ़ॉल्ट करेंcleanTask

Answer 8

टी एल; डॉ

test.dependsOn cleanTest

Comments

के अनुसार stackoverflow.com/a/52484259/466862 कि काम नहीं करेगा।

— मार्क रोटटेवेल

खैर, ग्रेडल डॉक्स थोड़ा भ्रमित कर रहे हैं .... यहां वे कहते हैं कि इस उद्देश्य के लिए क्लीनटेस्ट का उपयोग किया जा सकता है। docs.gradle.org/current/userguide/… । और यह भी, यह मेरी मशीन पर काम करता है (और ग्रेडल संस्करण 4.10.3);)

— टोपेरा

Answer 9

मुझे लगता है कि यह एक वैध प्रश्न है जो ग्रैडल में इस कमांड को चलाने के लिए संभव है test, और ऐसा क्या होता है कि कुछ भी नहीं होता है!

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

व्यक्तिगत रूप से मुझे लगता है कि यह ग्रैडल में एक (बहुत मामूली) डिज़ाइन दोष है: यदि "BUILD SUCCESSFUL" जाने के बजाय सब कुछ पूरी तरह से अद्यतित है, तो उसे "NO CHANGE SINCE LAST SUCCESSFIL BUILD: NOTHING DONE" कहना चाहिए।

Comments

"क्या आपको यह सोचने की ज़रूरत नहीं है कि आपके पास ये संदेह क्यों हैं, और उन्हें संबोधित करें?" क्या वह इतना पागल है?

— मुहस्तिथ

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

— दुलकीरेव

@dbalakirev हां, यह मेरे साथ हुआ ... लेकिन क्या आपको डोकर जैसे इन निर्भरताओं की भूमिका का मजाक नहीं उड़ाया जा सकता ...? मेरा मतलब है, यदि आप ऐसा नहीं कर रहे हैं , तो क्या आप भविष्य की समस्याओं का भंडारण नहीं कर रहे हैं? मैं यह नहीं कह रहा हूं कि मैं 100% निश्चित हूं, लेकिन मुझे क्या लगता है कि मैं कह रहा हूं कि आपके परीक्षण, दुनिया में हमारे आदर्श से अधिक आदर्श होने में कोई संदेह नहीं है, सभी आधारों को कवर करते हैं।

— माइक कृंतक

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

— dalakirev

__ यदि कोई कोड नहीं बदला है तो आपको पुन: परीक्षण की आवश्यकता क्यों है? __ क्या आपने एकीकरण परीक्षणों के बारे में सुना है?

— बोगडान मार्ट