সমস্ত পরীক্ষাগুলি ইউপি-টু-ডেটের সময়ে গ্রেডল পরীক্ষা কীভাবে চালাবেন?

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

প্রদত্ত তথ্যের ভিত্তিতে এটি অপ্রয়োজনীয় বলে মনে হচ্ছে। যদি অ্যাপ্লিকেশন কোড বা টেস্ট কোড দুটিই পরিবর্তিত হয় না, তবে আপনাকে কেন পরীক্ষাগুলি পুনরায় চালনার দরকার?

— Jolta

@ জোলতা আমার কোডের কয়েকটি পরীক্ষা 3-পক্ষের ইনপুট সম্পর্কিত, আমি কেবল কোডের ভিতরে কোনও ত্রুটি রাখিনি তা নিশ্চিত করার জন্য, 3-পক্ষের ইনপুটগুলিতে কিছু পরিবর্তন হয়েছে কিনা তা পরীক্ষা করে দেখার জন্য আমি আমার পরীক্ষা চালাচ্ছি যে আমি পাচ্ছি

— USer22999299

নিট-পিক হওয়ার জন্য দুঃখিত, তবে আমি সত্যিই এটি সম্পর্কে এটি ভাবনার সঠিক উপায় বলে মনে করি না: আপনার যদি পরিবর্তনশীল 3-পক্ষের ইনপুট থাকে তবে কোনওভাবেই এই ইনপুটগুলিকে উপহাস করার জন্য এটি সঠিকভাবে পরিচালনার উপায় নয়? টেস্টিংটি আসলে আপনি যে কোডটি লিখছেন তা পরীক্ষার বিষয়ে হওয়া উচিত। আপনি যদি অগ্রহণযোগ্য হওয়ার জন্য 3-পক্ষের ইনপুটটির উপর নির্ভর করে থাকেন তবে আপনি কি মিথ্যা-ইতিবাচক হওয়ার মোটামুটি স্পষ্ট বিপদের মধ্যে নেই? আপনার অ্যাপ্লিকেশন কোডটির অংশ হিসাবে সমস্যা ইনপুটটির জন্য কৌশলটি করা উচিত নয়?

— মাইক রডেন্ট

@ মাইক্রোডেন্ট আপনার তৃতীয় পক্ষের অনলাইন পরিষেবার বিরুদ্ধে কোডটি পরীক্ষা করার বিষয়ে বিবেচনা করুন। ASAP মোতায়েন করা ফিক্সগুলির সাথে প্রতিক্রিয়া জানাতে আপনি পরিষেবা API এ সম্ভাব্য পরিবর্তনগুলি নিরীক্ষণ করতে চান। সিআই পরীক্ষা কি এটি করার ভাল উপায় নয়? মক ব্যবহার করা কেবল আপনাকে জানাবে যে আপনার নিজের কোডটিতে রিগ্রেশন নেই, তবে নির্ভরতার এখনও পরিবর্তন হতে পারে। প্রকৃত পরিষেবাটি ব্যবহার করা ইঙ্গিত দেয় যে আপনার পণ্যটি বর্তমান পরিবেশে বাস্তবে প্রত্যাশিত ক্রিয়াকলাপ সম্পাদন করতে পারে।

— এলিস্ট

এটি একীকরণ পরীক্ষার দৃষ্টিকোণ থেকে এটিও বৈধ, যেখানে পরীক্ষার পয়েন্টটি আপনার কোডের অন্যান্য বিটের সাথে সংযুক্তি যাচাই করা হয়, যেখানে নির্ভরতাগুলিতে উপহাস করা উপযুক্ত হবে না

— 1800 তথ্য

Answer 1

একটি বিকল্প কমান্ড লাইনে--rerun-tasks পতাকা ব্যবহার করা হবে । এটি সমস্ত পরীক্ষার কাজ এবং এটি নির্ভর করে যে সমস্ত কার্য পুনরায় চালিত করে।

আপনি যদি কেবলমাত্র পরীক্ষাগুলি পুনরায় চালু করতে আগ্রহী হন তবে অন্য একটি বিকল্প হ'ল পরীক্ষাগুলি কার্যকর করার আগে গ্রেডগুলি পরীক্ষার ফলাফলগুলি পরিষ্কার করা। এটি cleanTestকাজটি ব্যবহার করে করা যেতে পারে ।

কিছু ব্যাকগ্রাউন্ড - জাভা প্লাগইন অন্য প্রতিটি কাজের জন্য একটি পরিষ্কার কাজ সংজ্ঞায়িত করে। ডকুমেন্টেশন অনুযায়ী :

ক্লিনটাস্কনাম - নির্দিষ্ট কাজ দ্বারা তৈরি করা ফাইল মুছে দেয়। ক্লিনজার জার টাস্ক দ্বারা তৈরি জার ফাইলটি মুছে ফেলবে, এবং ক্লিন টেস্ট পরীক্ষার কার্য দ্বারা তৈরি পরীক্ষার ফলাফল মুছে ফেলবে।

সুতরাং, আপনার পরীক্ষাগুলি পুনরায় চালনার জন্য আপনার যা প্রয়োজন তা হ'ল cleanTestকাজটি চালানোও, অর্থাত:
gradle cleanTest test

Comments

gradle cleanTest testপরীক্ষাগুলি পুনরায় চালিত করে না, এটি তাদের আউটপুট পরিষ্কার করে, তবে testটাস্কটি ক্যাশে থেকে এখনও পরীক্ষার ফলাফল পাবে

— github.com/gradle/gradle/issues/9153

উপরের মন্তব্যটি ঠিক। তবে আপনি যদি ব্যবহার করেন --no-build-cacheতবে এটি প্রত্যাশার মতো কাজ করবে, যেমন gradle cleanTest test --no-build-cache।

— vRallev

Answer 2

অন্য বিকল্পটি আপনার বিল্ড.gradle এ নিম্নলিখিত যুক্ত করা হবে:

test.outputs.upToDateWhen {false}

Comments

আমি funcTestকার্যকরী পরীক্ষা চালানোর জন্য তৈরি করা কোনও কাজের জন্য এই কৌশলটি ব্যবহার করেছি technique

— পার্সিকাল

এটি গ্রহণযোগ্য উত্তরের চেয়ে অনেক ভাল পদ্ধতির, কারণ এটি কেবলমাত্র কাঙ্ক্ষিত কাজে প্রয়োগ করা হবে। upToDateWhenযেমন সিস্টেম সম্পত্তি, এনভায়রনমেন্ট ভেরিয়েবল, প্রকল্প বৈশিষ্ট্য, ইত্যাদি কোন "কোড চালিত" ভাবে ব্যবহার করা যেতে পারে

— mkobit

উত্তর stackoverflow.com/a/52484259/340175 হিসাবে উল্লেখ করা হয়েছে, একটি দরকারী ব্লগ পোস্ট ব্লগ. gradle.org/stop-rerunning-tests রয়েছে যা ব্যাখ্যা করে যে কেন এই পদ্ধতির সাধারণ পদ্ধতির হিসাবে সুপারিশ করা হয় না। তবে আমি সম্মত হই যে এটি কার্যকর হতে পারে এবং প্রশ্নটি যা জিজ্ঞাসা করে তা অর্জন করে।

— জুলিয়ান হার্টি

হ্যাঁ, এটি তারিখের উত্তর, যখন আমি লিখেছিলাম এই গ্রেডলটি ২.১১ সংস্করণে ছিল এবং সবেমাত্র ব্যবহারযোগ্য হতে শুরু করেছিল, তবে এখনও অনেকগুলি রুক্ষ প্রান্ত ছিল, যা আজ পালিশ করা হয়েছে।

— ফ্রান্স্তিক হার্টম্যান

দুর্দান্ত উত্তর !!! একটি প্যারামিটার ব্যবহার করে এটি পাশ: gradle test -Prerun-tests। বিল্ড.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

"বিল্ড.gradle" ফাইলটি ব্যবহার করে এখানে একটি সমাধান দেওয়া হয়েছে, আপনি যদি আপনার কমান্ড লাইনটি পরিবর্তন করতে না চান তবে:

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

এবং এখানে আউটপুট। আপনার পূর্ববর্তী আউটপুট থেকে 2 টি পরিবর্তন লক্ষ্য করুন:

1) আউটপুটে একটি নতুন 'ক্লিন টেস্ট' টাস্ক উপস্থিত হবে।

2) 'পরীক্ষা' সর্বদা পরিষ্কার করা হয় (অর্থাত্ 'ইউপি-টু-ডেট' কখনই হয় না) তাই এটি প্রতিবার কার্যকর হয়:

$ 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

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

স্ট্যাকওভারফ্লো.com/a/52484259/466862 অনুসারে এটি কাজ করবে না।

— মার্ক রোটভেল

ওয়েল, গ্রেডল ডক্সটি কিছুটা বিভ্রান্তিকর .... এখানে তারা বলে যে ক্লিন টেস্ট এই উদ্দেশ্যে ব্যবহার করা যেতে পারে। docs.gradle.org/current/userguide/… । এবং এছাড়াও, এটি আমার মেশিনে কাজ করে (এবং গ্রেড সংস্করণ 4.10.3);)

— টোপেরা

Answer 9

আমি মনে করি এটি গ্রিডলে এই কমান্ডটি চালানো সম্ভব এবং এটি কী হয় তা হ'ল এটি একটি বৈধ প্রশ্ন test!

তবে আমি এটি করার জন্য প্রয়োজনটিকে প্রশ্ন করব, যেমনটি জোলতা তার মন্তব্যে বলেছিলেন: যদি কোনও কোড পরিবর্তন না হয় তবে আপনাকে পুনরায় পরীক্ষা করার দরকার কেন? যদি আপনার তৃতীয় পক্ষের ইনপুট সম্পর্কে সন্দেহ থাকে তবে আমি বলব যে আপনার অ্যাপ্লিকেশন কোডটিতে এটি করা দরকার। যদি আপনার উদ্বেগ থাকে যে আপনার কোডটি "ফ্লেকি" হতে পারে, অর্থাত্ প্রথমবারের মতো সমস্ত পরীক্ষায় উত্তীর্ণ হতে পারে তবে দ্বিতীয় (বা 100 তম বার) হতে পারে না, তবে কেন আপনার এই সন্দেহ রয়েছে এবং সেগুলি সমাধান করার জন্য আপনার কী ভাবার দরকার নেই?

ব্যক্তিগতভাবে আমি মনে করি এটি গ্রেডেলের একটি (খুব সামান্য) ডিজাইনের ত্রুটিযুক্ত: "বিল্ড সাফল্য" না যাওয়ার পরিবর্তে যদি সবকিছু সম্পূর্ণরূপে আপ টু ডেট থাকে তবে এটি "নট চেঞ্জ সাইনস লাস্ট সাফল্যসুলভ বিল্ড: কিছুই নয়" বলা উচিত।

Comments

"আপনার কেন এই সন্দেহ রয়েছে সেগুলি ভেবে আপনার কেন চিন্তা করার দরকার নেই এবং সেগুলি সমাধান করার দরকার নেই?": হ্যাঁ, তবে চিন্তা করার জন্য ডেটা পেতে, আমি কয়েকবার পরীক্ষা চালাতে চাই এবং কী হয় তা দেখতে চাই। এতো পাগল কি?

— মুহস্মীথ

@ মিকেরোডেন্ট আমি আপনার বক্তব্যের সাথে আংশিকভাবে একমত "সহজ" কেস রয়েছে, সাধারণত সহজ হোয়াইটবক্স ইউনিট পরীক্ষা, যেখানে কোনও কোড পরিবর্তন মানেই পুনরায় পরীক্ষা করা সত্যিকার অর্থে কিছুই নয়। নির্ভরতার সাথে পরীক্ষা সম্পর্কে চিন্তা করুন যদিও। "ওহ হ্যাঁ, ডকার চলছিল না ইত্যাদি।" সেখানে পরীক্ষাগুলি রয়েছে যেখানে এটি পরিকাঠামো (এবং আপনাকে দেব) যারা নির্ভরতা সেট করে (সেগুলি "সরবরাহ" করা হয়) এবং বিল্ডটি নয়। এই ক্ষেত্রে আমি সর্বদা পুনরায় চালাতে সক্ষম হতে চাই।

— dbalakirev

@ ডবালাকিরেভ হ্যাঁ, এটি আমার কাছে ঘটেছিল ... তবে আপনি কি এই নির্ভরশীলতার ভূমিকা যেমন ডকারের সাথে উপহাস করতে পারবেন না ...? মানে, আপনি যদি তা না করে থাকেন, তবে আপনি কি ভবিষ্যতের সমস্যাগুলি সঞ্চিত করছেন না? আমি বলছি না যে আমি 100% নিশ্চিত, তবে আমি যা মনে করি তা হ'ল আপনার পরীক্ষাগুলি কোনও বিশ্বে অবশ্যই আমাদের চেয়ে বেশি আদর্শ হওয়া উচিত, সমস্ত ঘাঁটি coverেকে রাখা উচিত।

— মাইকে রডেন্ট

আপনি হ্যাঁ উপহাস করতে পারেন, যার সাথে আপনার নির্ভরতা রয়েছে (ডকার) যে যদি আপনার ব্যর্থ হয় তবে এর অর্থ আপনি কোডটি পরিবর্তন না করলেও আপনি আবার চালনা করতে চান। আমি এই চিন্তাকে জোর দিয়ে বলতে চাই যে ইউনিট পরীক্ষা বা পরীক্ষার জন্য নয় যেখানে ১। আপনি নির্ভরতা এড়ানোর চেষ্টা করেন ২. বা কমপক্ষে পরীক্ষার কাঠামোটি ব্যবহার করে তাদের বিদ্রূপ করুন, তবে যখন তারা সত্যই "সরবরাহিত" হবে আপনি যদি চান।

— dbalakirev

__ যদি কোনও কোড পরিবর্তিত হয় না তবে আপনাকে পুনরায় পরীক্ষা করার দরকার কেন? __ আপনি কি ইন্টিগ্রেশন পরীক্ষার কথা শুনেছেন?

— বোগদান মার্ট