простой способ-добавить явную зависимость задачи в ProjectB:

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

сложным (но более понятным) способом является создание дополнительной конфигурации артефакта для ProjectA:

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

configurations {
  testArtifacts
}

artifacts {
   testArtifacts myTestsJar
}

и добавить testCompile зависимость для ProjectB

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

Я знаю, что это старый вопрос, но я просто имел ту же проблему и потратил некоторое время, выясняя, что происходит. Я использую Gradle 1.9. Все изменения должны быть в ProjectB build.gradle

использовать тестовые классы из ProjectA в тестах ProjectB:

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

чтобы убедиться, что sourceSets свойство доступно для проекта:

evaluationDependsOn(':ProjectA')

чтобы убедиться, что тестовые классы из ProjectA на самом деле есть, когда вы компилируете ProjectB:

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

Я сам недавно столкнулся с этой проблемой, и человек-это трудные вопросы, на которые нужно найти ответы.

ошибка, которую вы делаете, заключается в том, что проект должен экспортировать свои тестовые элементы таким же образом, как он экспортирует свои основные артефакты и зависимости.

то, что у меня было намного больше успеха лично, было создание нового проекта в Gradle. В вашем примере я бы назвал его

Проект A_Test - >src / main / java

Я бы поставил в src / main/java файлы, которые в настоящее время находятся в Project A/src/test / java. Сделайте все зависимости testCompile вашего проекта компилируемыми зависимостями проекта A_Test.

затем сделайте Project A_Test зависимостью testCompile проекта B.

Это не логично, когда вы подходите к этому с точки зрения автора обоих проектов, но я думаю, что это имеет большой смысл, когда вы думаете о таких проектах, как junit и scalatest (и другие. Даже если те фреймворки связаны с тестированием, они не считаются частью "тестовых" целей в своих собственных фреймворках - они создают первичные артефакты, которые другие проекты просто используют в своей тестовой конфигурации. Вы просто хотите следовать той же схеме.

попытка сделать другие ответы, перечисленные здесь, не сработала для меня лично (используя Gradle 1.9), но я обнаружил, что шаблон, который я описываю здесь, в любом случае является более чистым решением.

новое решение на основе testJar (поддерживается trnsitive dependancies) доступно в виде плагина gradle:

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

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

из документации

в случае, если у вас есть несколько проектов gradle сборки вы можете иметь тест зависимости между подпроектами (что, вероятно, является намеком на то, что ваш проекты не очень хорошо структурированы).

например, предположим, что проект, где подпроект проекта B зависит в проекте A и B не только есть зависимость компиляции от A, но также тестовая зависимость. Для компиляции и запуска тестов B нам нужны некоторые тест вспомогательные классы от А.

ш по умолчанию не создает банку артефактов из тестовой версии вывод проекта.

этот плагин добавляет конфигурацию testArchives (на основе testCompile) и задача jarTest для создания jar из исходного набора тестов (с помощью классификатор теста добавлен в название банки). Тогда мы можем рассчитывать на б о конфигурация testArchives A (которая также будет включать транзитивных зависимостей).

В A мы бы добавили плагин для сборки.Gradle в:

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

В B мы ссылаемся на конфигурация testArchives выглядит следующим образом:

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

пожалуйста, прочитайте обновление ниже.

аналогичные проблемы, описанные JustACluelessNewbie, возникают в IntelliJ IDEA. Проблема в том, что зависимость testCompile project(':core').sourceSets.test.output на самом деле означает: "зависит от классов, созданных gradle build task". Поэтому, если вы откроете чистый проект, где классы еще не созданы, идея не распознает их и сообщает об ошибке.

чтобы устранить эту проблему, вы должны добавить зависимость от исходных файлов теста рядом с зависимостью от скомпилированного занятия.

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

вы можете наблюдать зависимости, признанные идеей в настройки модуля - > зависимости (область тестирования).

кстати. это не очень хорошее решение, поэтому рефакторинг стоит рассмотреть. Сам Gradle имеет специальный подпроект, содержащий только классы поддержки тестов. Смотрите https://docs.gradle.org/current/userguide/test_kit.html

обновление 2016-06-05 Больше я думаю о предлагаемом решении меньше я нравится. Есть несколько проблем с этим:

1. он создает две зависимости в идее. Один указывает на тестовые источники, другой-на скомпилированные классы. И очень важно, в каком порядке эти зависимости признаются идеей. Вы можете играть с ним, изменив порядок зависимостей в настройках модуля - > вкладка зависимости.
2. объявляя эти зависимости, вы излишне загрязняете структуру зависимостей.

Так что же лучше решение? В моем мнение он создает новый пользовательский исходный набор и помещает в него общие классы. На самом деле авторы проекта Gradle сделали это, создав исходный набор testFixtures.

для этого вам просто надо:

1. создать исходный набор и добавить необходимые конфигурации. Проверьте этот плагин сценария, используемый в проекте Gradle:https://github.com/gradle/gradle/blob/master/gradle/testFixtures.gradle

2. заявить, собственно зависимость от проект:

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

3. импортируйте проект Gradle в IDEA и используйте опцию "создать отдельный модуль для исходного набора" при импорте.

решение Fesler не сработало для меня, когда я попытался построить проект android (gradle 2.2.0). Поэтому мне пришлось ссылаться на необходимые классы вручную:

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

некоторые из других ответов вызвали ошибки так или иначе-Gradle не обнаружил тестовые классы из других проектов или проект Eclipse имел недопустимые зависимости при импорте. Если у кого-то есть такая же проблема, я предлагаю пойти с:

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

первая строка заставляет Eclipse связывать другой проект как зависимость, поэтому все источники включены и обновлены. Второй позволяет Gradle фактически видеть источники, не вызывая при этом никаких недопустимых ошибок зависимостей, таких как testCompile project(':core').sourceSets.test.output делает.

в проекте B:

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

Кажется, работает в 1.7-rc-2

если у вас есть макет зависимостей, которые нужно разделить между тестами, вы можете создать новый проект projectA-mock а затем добавить его в качестве тестовой зависимости в ProjectA и ProjectB:

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

это понятное решение для совместного использования фиктивных зависимостей, но если вам нужно запустить тесты из ProjectA на ProjectB использовать другое решение.

Я так поздно на вечеринку (теперь это Gradle v4. 4), но для всех, кто находит это:

перейти к сборке.gradle проекта B (тот, который нуждается в некоторых тестовых классах из A) и добавить следующее:

  android {
    ...
    sourceSets {
    String sharedTestDir = '../module-b/src/test/java'
        test {
            java.srcDir sharedTestDir
        }
    }
   ...
  }

вуаля!