गुणन के साथ बहु-परियोजना परीक्षण निर्भरताएँ

Question

मेरे पास एक मल्टी-प्रोजेक्ट कॉन्फ़िगरेशन है और मैं ग्रेडेल का उपयोग करना चाहता हूं।

मेरी परियोजनाएं इस प्रकार हैं:

• प्रोजेक्ट ए

  • -> src/main/java
  • -> src/test/java

• प्रोजेक्ट बी

  • -> src/main/java( प्रोजेक्ट Asrc/main/java पर निर्भर करता है )
  • -> src/test/java( प्रोजेक्ट Asrc/test/java पर निर्भर करता है )

मेरा प्रोजेक्ट बी build.gradle फ़ाइल इस प्रकार है:

apply plugin: 'java'
dependencies {
  compile project(':ProjectA')
}

कार्य compileJavaबहुत अच्छा है, लेकिन प्रोजेक्ट एcompileTestJava से परीक्षण फ़ाइल को संकलित नहीं करता है ।

Comments

संभव डुप्लिकेट: stackoverflow.com/questions/5144325/gradle-test-d

— dependency

Answer 1

पदावनत - ग्रेडेल 5.6 और इसके बाद के संस्करण इस उत्तर का उपयोग करते हैं ।

में परियोजना बी , आप सिर्फ एक जोड़ने की जरूरत है testCompileनिर्भरता:

dependencies {
  ...
  testCompile project(':A').sourceSets.test.output
}

ग्रैडल 1.7 के साथ परीक्षण किया गया।

Comments

वर्गों का गुणन खंडित हो जाता है - इसके बजाय आउटपुट का उपयोग करें।

— फेसलर

यह ग्रैडल 1.3 में काम नहीं करता है क्योंकि sourceSets अब किसी परियोजना की सार्वजनिक संपत्ति नहीं है।

— डेविड पैर्सन

ध्यान रखें कि उपरोक्त gradle testClassesसंरचना को वास्तव में वैध बनाने से पहले कम से कम समाधान की आवश्यकता है। उदाहरण के लिए ग्रहण प्लगइन आपको इससे पहले परियोजना को आयात नहीं करने देगा। यह वास्तव में शर्म की बात testCompile project(':A')है काम नहीं करता है। @ डेविडपर्सन: "ग्रैडल 1.3" विरोधाभास "अब नहीं" के बाद से फेसलर ने ग्रैडल 1.7 के साथ परीक्षण किया।

— पैट्रिक बर्गनर

मेरे लिए काम नहीं किया। परिपत्र निर्भरता के साथ विफल: compileTestJava \ ---: testClasses \ ---: compileTestJava (*)

— rahulmohan

ऐसा न करें, परियोजनाओं को अन्य परियोजनाओं में नहीं जाना चाहिए। इसके बजाय निकिता के जवाब का उपयोग करें, इसे प्रोजेक्ट निर्भरता के रूप में सही ढंग से मॉडलिंग करें।

— स्टीफन ओहमे

Answer 2

सरल तरीका ProjectB में स्पष्ट कार्य निर्भरता को जोड़ना है:

compileTestJava.dependsOn tasks.getByPath(':ProjectA:testClasses')

प्रोजेक्टा के लिए अतिरिक्त विरूपण साक्ष्य विन्यास बनाने के लिए कठिन (लेकिन अधिक स्पष्ट) तरीका है:

task myTestsJar(type: Jar) { 
  // pack whatever you need...
}

configurations {
  testArtifacts
}

artifacts {
   testArtifacts myTestsJar
}

और testCompileProjectB के लिए निर्भरता जोड़ें

apply plugin: 'java'
dependencies {
  compile project(':ProjectA')
  testCompile project(path: ':ProjectA', configuration: 'testArtifacts')
}

Comments

मैंने यह (सरल तरीका) आजमाया और जबकि यह सुनिश्चित करता है कि यह testClasses का निर्माण करता है, यह CLASSPATH के लिए परीक्षण पथ को नहीं जोड़ता है इसलिए मेरे ProjectB परीक्षण जो ProjectA परीक्षण कक्षाओं पर निर्भर करते हैं अभी भी बनाने में विफल हैं।

— पीजेड

@dmoebius को आपको testArtifactsइस तरह से कॉन्फ़िगरेशन जोड़ना होगा: configurations { testArtifacts } अधिक जानकारी के लिए ग्रेडेल

— निकिता

ग्रैडल 1.8 में आप चाहते हैं from sourceSets.test.outputऔर संभवतः उत्तर classifier = 'tests'में जगह ले सकते हैं// pack whatever you need...

— पीटर लैम्बबर्ग

पुष्टि की कि ग्रेडेल 1.12 के साथ पूर्ण समाधान का उपयोग करते हुए, @PeterLamberg ने सुझाव दिया कि परिवर्धन अपेक्षा के अनुरूप काम करता है। ग्रहण में परियोजना के आयात को प्रभावित नहीं करता है।

— 22

यह ग्रैडल 4.7 में मेरे लिए काम करता है। अब उनके पास docs.gradle.org/current/dsl/…

— नाथन विलियम्स

Answer 3

यह अब ग्रैडल में प्रथम श्रेणी की सुविधा के रूप में समर्थित है। प्लगइन्स javaया java-libraryप्लगइन्स के साथ एक java-test-fixturesप्लगइन भी शामिल हो सकता है जो सहायक वर्गों और संसाधनों को उजागर करता है जिसका उपयोग testFixturesसहायक के साथ किया जाता है । कलाकृतियों और क्लासिफायर के खिलाफ इस दृष्टिकोण के लाभ हैं:

• उचित निर्भरता प्रबंधन (कार्यान्वयन / एपीआई)
• परीक्षण कोड से अच्छा अलगाव (अलग स्रोत सेट)
• केवल उपयोगिताओं को उजागर करने के लिए परीक्षण कक्षाओं को फ़िल्टर करने की कोई आवश्यकता नहीं है
• ग्रेडल द्वारा बनाए रखा

उदाहरण

:modul:one

मॉड्यूलर / एक / build.gradle

plugins {
  id "java-library" // or "java"
  id "java-test-fixtures"
}

मॉड्यूलर / एक / src / testFixtures / जावा / com / उदाहरण / Helper.java

package com.example;
public class Helper {}

:modul:other

मॉड्यूलर / अन्य / build.gradle

plugins {
  id "java" // or "java-library"
}
dependencies {
  testImplementation(testFixtures(project(":modul:one")))
}

मॉड्यूलर / अन्य / src / परीक्षण / जावा / com / उदाहरण / अन्य / SomeTest.java

package com.example.other;
import com.example.Helper;
public class SomeTest {
  @Test void f() {
    new Helper(); // used from :modul:one's testFixtures
  }
}

आगे की पढाई

अधिक जानकारी के लिए, दस्तावेज़ देखें:
https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures

इसे 5.6 में जोड़ा गया था:
https://docs.gradle.org/5.6/release-notes.html#test-fixtures-for-java-projects

Comments

वे Android पर इस समर्थन पर काम कर रहे, देखने issuetracker.google.com/issues/139762443 और issuetracker.google.com/issues/139438142

— अल्बर्ट विला कैल्वो

Answer 4

मैं हाल ही में इस समस्या को लेकर आया हूं, और इसका जवाब खोजने के लिए मनुष्य एक कठिन मुद्दा है।

आप जो गलती कर रहे हैं वह सोच रहा है कि एक परियोजना को अपने परीक्षण तत्वों को उसी तरह से निर्यात करना चाहिए जिस तरह से वह अपनी प्राथमिक कलाकृतियों और निर्भरता को निर्यात करता है।

मुझे व्यक्तिगत रूप से ग्रैडल में एक नई परियोजना बनाने में बहुत अधिक सफलता मिली। आपके उदाहरण में, मैं इसका नाम दूंगा

प्रोजेक्ट A_Test -> src / main / java

मैं src / main / java में उन फ़ाइलों को डालूँगा जो आपके पास वर्तमान में Project A / src / test / java में हैं। अपने प्रोजेक्ट की कोई भी परीक्षणकंपनी निर्भरता बनाएं प्रोजेक्ट A_Test की संकलित निर्भरताएँ।

फिर प्रोजेक्ट A_Test को प्रोजेक्ट B की एक परीक्षणकंप्ली निर्भरता बनाएं।

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

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

Comments

हां, दिन के अंत में इस दृष्टिकोण का विकल्प चुना।

— कोमा

यह सबसे अच्छा तरीका है! सिवाय मैं परीक्षण कोड को प्रोजेक्ट ए में रखूँगा और केवल ए / एसस्ट / टेस्ट / जावा और बी एसकेसी / टेस्ट / जावा दोनों के लिए निर्भरता को आगे बढ़ाएगा। फिर प्रोजेक्ट A_Test को A और B. दोनों का एक परीक्षण कार्यान्वयन निर्भरता बनाएं

— Erik Sillén

Answer 5

मुझे पता है कि यह एक पुराना सवाल है, लेकिन मुझे बस एक ही समस्या थी और कुछ समय लगा रहा था कि क्या हो रहा है। मैं ग्रेडल 1.9 का उपयोग कर रहा हूं। सभी परिवर्तन प्रोजेक्टबी में होने चाहिएbuild.gradle

ProjectB के परीक्षण में ProjectA से परीक्षण कक्षाओं का उपयोग करने के लिए:

testCompile files(project(':ProjectA').sourceSets.test.output.classesDir)

यह सुनिश्चित करने के लिए कि sourceSetsProjectA के लिए संपत्ति उपलब्ध है:

evaluationDependsOn(':ProjectA')

यह सुनिश्चित करने के लिए कि प्रोजेक्टा से परीक्षण कक्षाएं वास्तव में हैं, जब आप प्रोजेक्टबी को संकलित करते हैं:

compileTestJava.dependsOn tasks.getByPath(':ProjectA:testClasses')

Comments

यह मेरे लिए भी काम करता है सिवाय इसके कि मुझे छोड़ना पड़े .classesDir।

Answer 6

न्यू टेस्टजेर बेस्ड (ट्रान्सेटिव डिपेंडेंट समर्थित) सॉल्यूशन प्लगइन के रूप में उपलब्ध समाधान:

https://github.com/hauner/gradle-plugins/tree/master/jartest

https://plugins.gradle.org/plugin/com.github.hauner.jarTest/1.0

प्रलेखन से

यदि आपके पास एक मल्टी-प्रोजेक्ट ग्रेडेल बिल्ड है, तो आपके पास उप-परियोजनाओं के बीच परीक्षण निर्भरता हो सकती है (जो संभवतः एक संकेत है कि आपकी परियोजनाएं अच्छी तरह से संरचित नहीं हैं)।

उदाहरण के लिए, एक परियोजना मान लीजिए कि उप-परियोजना प्रोजेक्ट बी प्रोजेक्ट ए पर निर्भर करता है और बी में केवल ए पर एक संकलन निर्भरता नहीं है, बल्कि एक परीक्षण निर्भरता भी है। बी के परीक्षणों को संकलित करने और चलाने के लिए हमें ए से कुछ परीक्षण सहायक वर्गों की आवश्यकता है।

डिफ़ॉल्ट रूप से एक प्रोजेक्ट के टेस्ट बिल्ड आउटपुट से जार आर्टवर्क नहीं बनता है।

यह प्लगइन एक testArchives विन्यास (testCompile पर आधारित) और एक jarTest कार्य को परीक्षण स्रोत सेट से जार बनाने के लिए जोड़ता है (साथ में वर्गीकरण का परीक्षण जार के नाम के साथ जोड़ा गया)। हम तब ए के टेस्टआर्इव्स कॉन्फ़िगरेशन पर बी पर निर्भर कर सकते हैं (जिसमें ए की सकर्मक निर्भरता भी शामिल होगी)।

A में हम build.gradle के लिए प्लगइन जोड़ेंगे:

apply plugin: 'com.github.hauner.jarTest'

बी में हम इस तरह परीक्षण विन्यास का संदर्भ देते हैं:

dependencies {
    ...
    testCompile project (path: ':ProjectA', configuration: 'testArchives') 
}

Comments

हालांकि यह लिंक प्रश्न का उत्तर दे सकता है, लेकिन उत्तर के आवश्यक भागों को शामिल करना और संदर्भ के लिए लिंक प्रदान करना बेहतर है। लिंक-केवल उत्तर अमान्य हो सकते हैं यदि लिंक किए गए पृष्ठ बदल जाते हैं। - समीक्षा से

— इयान

पाठ की कुछ पंक्तियों को जोड़ा गया है

— demon101

वैसे भी, नए ग्रेडल प्लगइन के बारे में जानकारी प्रदान की गई है।

— demon101

@ demon101 ग्रैडल 4.6 में काम नहीं कर रहा है, त्रुटि हो रही हैCould not get unknown property 'testClasses' for project ':core' of type org.gradle.api.Project.

— विग्नेश सुंदर

Answer 7

कृपया अपडेट को पढ़ें।

JustACluelessNewbie द्वारा वर्णित समान समस्याएं IntelliJ IDEA में होती हैं। समस्या यह है कि testCompile project(':core').sourceSets.test.outputवास्तव में निर्भरता का अर्थ है: "ग्रेडल बिल्ड कार्य द्वारा उत्पन्न वर्गों पर निर्भर"। इसलिए यदि आप स्वच्छ परियोजना खोलते हैं जहां कक्षाएं अभी तक उत्पन्न नहीं हुई हैं, तो आईडिया उन्हें पहचान नहीं पाएगा और त्रुटि की रिपोर्ट करेगा।

इस समस्या को ठीक करने के लिए आपको संकलित कक्षाओं पर निर्भरता के बगल में परीक्षण स्रोत फ़ाइलों पर निर्भरता को जोड़ना होगा।

// First dependency is for IDEA
testCompileOnly files { project(':core').sourceSets.test.java.srcDirs }
// Second is for Gradle
testCompile project(':core').sourceSets.test.output

आप मॉड्यूल सेटिंग्स में IDEA द्वारा मान्यता प्राप्त निर्भरता का निरीक्षण कर सकते हैं -> निर्भरता (परीक्षण गुंजाइश) ।

Btw। यह अच्छा समाधान नहीं है इसलिए रिफ्लेक्टिंग विचार करने योग्य है। ग्रैडल में केवल विशेष उपप्रोजेक्ट होते हैं जिनमें केवल परीक्षण-सहायता कक्षाएं होती हैं। Https://docs.gradle.org/current/userguide/test_kit.html देखें

अपडेट 2016-06-05 अधिक मैं प्रस्तावित समाधान के बारे में सोच रहा हूं मुझे यह पसंद है। इसके साथ कुछ समस्याएं हैं:

1. यह IDEA में दो निर्भरताएँ बनाता है। संकलित कक्षाओं के लिए एक और स्रोत का परीक्षण करने के लिए एक अंक। और यह महत्वपूर्ण है कि किस क्रम में ये निर्भरता IDEA द्वारा मान्यता प्राप्त है। आप मॉड्यूल सेटिंग्स में निर्भरता क्रम बदलकर इसके साथ खेल सकते हैं -> निर्भरता टैब।
2. इन निर्भरताओं की घोषणा करके आप अनावश्यक रूप से निर्भरता संरचना को प्रदूषित कर रहे हैं।

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

इसे करने के लिए आपको बस यह करना है:

1. स्रोत सेट बनाएं और आवश्यक कॉन्फ़िगरेशन जोड़ें। ग्रेड प्रोजेक्ट में प्रयुक्त इस स्क्रिप्ट प्लगइन की जाँच करें: https://github.com/gradle/gradle/blob/v4.0.0/gradle/testFixtures.gradle

2. निर्भर परियोजना में उचित निर्भरता की घोषणा:

   dependencies {
       testCompile project(path: ':module-with-shared-classes', configuration: 'testFixturesUsageCompile')
   }
   

3. आयात ग्रेड परियोजना को आईडिया के लिए और आयात करते समय "प्रति स्रोत सेट अलग मॉड्यूल बनाएँ" विकल्प का उपयोग करें।

Comments

github.com/gradle/gradle/blob/master/gradle/testFixtures.gradle लिंक मृत है

— jannis

@ जांनि तय Btw। ग्रैडल ने अपने ग्रूवी आधारित परीक्षण जुड़नार प्लगइन को नए कोटलिन आधारित: github.com/gradle/gradle/blob/v5.0.0/buildSrc/subprojects/…

— Václav Kužel

@ VáclavKužel मैं अपने ब्लॉग पोस्ट के माध्यम से आपके दिलचस्प समाधान का पता लगाता हूं और इसने मेरे मुद्दे को बहुत अच्छी तरह से हल किया। धन्यवाद;)

— zaerymoghaddam

Answer 8

फ़ेसलर के समाधान ने मेरे लिए काम नहीं किया है, जब मैंने इसे एक एंड्रॉइड प्रोजेक्ट बनाने का प्रयास किया (2.2.0)। इसलिए मुझे आवश्यक वर्गों को मैन्युअल रूप से संदर्भित करना पड़ा:

android {
    sourceSets {
        androidTest {
            java.srcDir project(':A').file("src/androidTest/java")
        }
        test {
            java.srcDir project(':A').file("src/test/java")
        }
    }
}

Comments

मामूली टाइपो, परियोजना के बाद अंतिम उद्धरण याद कर रहा है (': ए')। इसने मेरे लिए काम किया, धन्यवाद m8

— रयान न्यूजॉम

एंड्रॉइड के लिए यह विचार मेरे लिए खूबसूरती से काम करता है, बिना

— हैकी

@ हर्बर्ग हां, एक अच्छा तरीका है। केवल एक सीमा जो मैं देख रहा हूं वह @VisibleForTestingलिंट नियमों के साथ है। आप परीक्षण फ़ोल्डर के तहत नियमित मॉड्यूल से ऐसे तरीकों को कॉल करने में सक्षम नहीं होंगे।

— बेलू

Answer 9

मुझे पार्टी में बहुत देर हो चुकी है (यह अब ग्रेडल v4.4 है) लेकिन किसी और के लिए जो इसे पाता है:

मान लिया जाये कि:

~/allProjects
|
|-/ProjectA/module-a/src/test/java
|
|-/ProjectB/module-b/src/test/java

प्रोजेक्ट B के build.gradle पर जाएं (वह जिसे A से कुछ परीक्षण कक्षाओं की आवश्यकता है) और निम्नलिखित जोड़ें:

sourceSets {
    String sharedTestDir = "${projectDir}"+'/module-b/src/test/java'
    test {
        java.srcDir sharedTestDir
    }
}

या (आपकी परियोजना को "प्रोजेक्टबी" नाम दिया गया है)

sourceSets {
    String sharedTestDir = project(':ProjectB').file("module-b/src/test/java")
    test {
        java.srcDir sharedTestDir
    }
}

देखा!

Comments

प्रश्न में एंड्रॉइड का उल्लेख नहीं है। क्या आप अपना जवाब अज्ञेयवादी बना सकते हैं कि डेवलपर एंड्रॉइड के लिए विकसित हो रहा है या नहीं, या यह केवल एंड्रॉइड डेवलपर्स के लिए है?

— रॉबिन ग्रीन

Answer 10

आप नकली निर्भरता जो आप परीक्षण के बीच साझा करने की आवश्यकता है, तो आप नई परियोजना बना सकते हैं projectA-mockऔर फिर यह परीक्षण निर्भरता के रूप में करने के लिए जोड़ ProjectAऔर ProjectB:

dependencies {
  testCompile project(':projectA-mock')
}

यह साझा नकली निर्भरता के लिए स्पष्ट समाधान है, लेकिन आप से परीक्षण चलाने के लिए की जरूरत है ProjectAमें ProjectBअन्य समाधान उपयोग।

Comments

साझा नकली मामले के लिए महान समाधान!

— एरिक सिलीन

Answer 11

यदि आप विरूपण साक्ष्य निर्भरता का उपयोग करना चाहते हैं:

• प्रोजेक्टबी के स्रोत वर्ग प्रोजेक्ट ए के स्रोत वर्गों पर निर्भर करते हैं
• ProjectB की परीक्षण कक्षाएं Project A की परीक्षण कक्षाओं पर निर्भर करती हैं

उसके बाद ProjectB की निर्भरता build.gradle खंड में कुछ इस तरह दिखनी चाहिए:

dependencies {

  compile("com.example:projecta:1.0.0")

  testCompile("com.example:projecta:1.0.0:tests")

}

इस कार्य के लिए ProjectA को -tests जार बनाने और इसे अपने द्वारा निर्मित कलाकृतियों में शामिल करने की आवश्यकता है ।

ProjectA's build.gradle में कॉन्फ़िगरेशन इस तरह होना चाहिए:

task testsJar(type: Jar, dependsOn: testClasses) {
    classifier = 'tests'
    from sourceSets.test.output
}

configurations {
    tests
}

artifacts {
    tests testsJar
    archives testsJar
}

jar.finalizedBy(testsJar)

जब ProjectA की कलाकृतियों को आपकी कलाकृतियों में प्रकाशित किया जाता है, तो वे एक- टट्टी जार शामिल करेंगी ।

TestCompile ProjectB की निर्भरता खंड में में कक्षाओं में लाना होगा -tests जार।

---

यदि आप ProjectA के स्रोत और परीक्षण कक्षाओं को ProjectB में विकास के उद्देश्यों के लिए शामिल करना चाहते हैं, तो ProjectB के build.gradle में निर्भरता अनुभाग इस तरह दिखाई देगा:

dependencies {

  compile project(':projecta')

  testCompile project(path: ':projecta', configuration: 'tests')

}

Comments

दुर्भाग्य से (ग्रैडल 6 में) फ्लैट शामिल हैं, जो कि वास्तव में मैं चाहता था, अब और काम नहीं करता है क्योंकि अब कोई कॉन्फ़िगरेशन 'परीक्षण' नहीं है। का उपयोग करते हुए println(configurations.joinToString("\n") { it.name + " - " + it.allDependencies.joinToString() })(एक कोटलिन बिल्डडस्क्रिप्ट में), मैंने निर्धारित किया कि कौन से कॉन्फ़िगरेशन अभी भी मौजूद हैं और निर्भरताएं हैं, लेकिन इन सभी के लिए Selected configuration 'testCompileClasspath' on 'project :sdk' but it can't be used as a project dependency because it isn't intended for consumption by other components.

— ग्रैडल

Answer 12

अन्य उत्तरों में से कुछ ने त्रुटियों को एक तरह से या किसी अन्य कारण से उत्पन्न किया - ग्रैडल ने अन्य परियोजनाओं से परीक्षण कक्षाओं का पता नहीं लगाया या ग्रहण परियोजना में आयात के रूप में अमान्य निर्भरताएं थीं। अगर किसी को एक ही समस्या है, तो मेरा सुझाव है:

testCompile project(':core')
testCompile files(project(':core').sourceSets.test.output.classesDir)

पहली पंक्ति ग्रहण को अन्य परियोजना को निर्भरता के रूप में जोड़ने के लिए मजबूर करती है, इसलिए सभी स्रोत शामिल हैं और आज तक हैं। दूसरा ग्रैडल को वास्तव में स्रोतों को देखने की अनुमति देता है, जबकि किसी भी तरह की अवैध निर्भरता त्रुटियों का कारण नहीं testCompile project(':core').sourceSets.test.outputहै।

Answer 13

यहां अगर आप कोटलिन डीएसएल का उपयोग कर रहे हैं , तो आपको ग्रैडल के अनुसार अपना कार्य बनाना चाहिए डॉक्यूमेंटेशन के ।

पिछले कुछ उत्तर की तरह, आपको प्रोजेक्ट के अंदर एक विशेष कॉन्फ़िगरेशन बनाने की आवश्यकता है जो इसके परीक्षण वर्ग को साझा करेगा, ताकि आप परीक्षण और मुख्य कक्षाओं को न मिलाएं।

सरल कदम

1. में परियोजना एक आप अपने में जोड़ने के लिए की आवश्यकता होगी build.gradle.kts:

configurations {
    create("test")
}

tasks.register<Jar>("testArchive") {
    archiveBaseName.set("ProjectA-test")
    from(project.the<SourceSetContainer>()["test"].output)
}

artifacts {
    add("test", tasks["testArchive"])
}

2. तो निर्भरता में अपनी परियोजना बी में, आपको अपने में जोड़ना होगा build.gradle.kts:

dependencies {
    implementation(project(":ProjectA"))
    testImplementation(project(":ProjectA", "test"))
}

Answer 14

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

dependencies {
  testCompile project(':projectA').sourceSets.test.output
}

1.7-rc-2 में काम करने लगता है

Comments

यह ग्रहण द्वारा परियोजना के संचालन में अनावश्यक जटिलताएं भी पैदा करता है। @NikitaSkvortsov द्वारा सुझाए गए समाधान बेहतर है।

— sfitts