Skip tests with gradle? - java tutorials

14 ответов

Лучший ответ

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

Пытаться:

Обновление:

Ссылка в комментарии Питера изменилась. Вот диаграмма из Руководство пользователя Gradle

1380

David Avendasora
30 Дек 2017 в 14:17

Пытаться:

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

ОБНОВИТЬ:

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

118

Paul Verest
25 Апр 2014 в 10:45

Принятый ответ — правильный.

OTOH, я ранее решил эту проблему, добавив во все проекты следующее:

Запустите сборку с , и все тестовые задачи будут пропущены.

Jacek Laskowski
11 Мар 2014 в 20:44

Вы можете добавить следующие строки в , исключает все тесты.

Guisong He
23 Мар 2019 в 03:15

Вы можете исключить задачи

Pehmolelu
17 Апр 2019 в 12:17

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

В нашем случае у нас есть процесс CI / CD, где одна цель — компиляция, а следующая цель — тестирование (Сборка -> Тест).

Итак, для нашей первой цели мы хотели убедиться, что весь проект хорошо компилируется. Для этого мы использовали:

По следующей цели мы просто выполняем тесты.

Federico Piazza
3 Мар 2020 в 17:57

Чтобы исключить любую задачу из Gradle, используйте опцию командной строки . См. Пример ниже

Вывод:

Надеюсь, это даст вам основные

Henrik Aasted Sørensen
12 Июн 2017 в 09:56

Другой способ отключить тестовые задачи в проекте:

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

Этот способ работает для всех видов тестовых задач, а не только для java-тестов. Кроме того, этот способ безопасен. Вот что я имею в виду допустим: у вас есть набор проектов на разных языках: если мы попытаемся добавить такую запись в основной :

Мы потерпим неудачу в проекте, если у нас нет задачи под названием тесты

Sergey Yakovlev
3 Май 2018 в 12:01

Каждое действие в gradle — это , как и . А чтобы исключить из выполнения gradle, вы можете использовать параметр или его сокращенное обозначение , за которым следует имя задачи, которую необходимо исключить. Пример:

Опцию следует повторить для всех задач, которые необходимо исключить.

Если у вас есть разные задачи для разных типов тестов в вашем файле , вам нужно пропустить все те задачи, которые выполняет тест. Допустим, у вас есть задача , которая выполняет модульные тесты, и задача , которая выполняет функциональные тесты. В этом случае вы можете исключить все тесты, как показано ниже:

Sahil Chhabra
10 Авг 2020 в 08:16

Вы можете использовать gradle build -x test

Это исключит тесты.

Sourabh Bhavsar
1 Апр 2021 в 08:41

Если у вашей машины несколько ядер. Однако не рекомендуется использовать параллельную очистку.

Yan Khonski
31 Май 2017 в 08:26

Пожалуйста, попробуйте это:

d4vsanchez
6 Июл 2019 в 06:34

В подключаемом модуле Java:

Сборка Gradle без теста у вас есть два варианта:

Но если вы хотите скомпилировать тест:

Arnau Sistach Reinoso
17 Мар 2020 в 07:55

Вам нужно будет добавить

Например

или

Paresh Mangukiya
27 Авг 2020 в 03:45

Конфигурация задачи

Расширим предыдущий пример, добавив блок конфигурации:

Запустив файл, мы получим результат, который покажется нам нелогичным:

Для обозначения блока кода между парой фигурных скобок, в Groovy используется термин «замкнутое выражение» или «замыкание» (closure). Функции-замыкания подобны объектам, которые можно передавать методу как параметр или присваивать переменной, с возможностью последующего выполнения. Они будут повсеместно встречаться вам в Gradle, поскольку в высшей степени подходят в роли блоков, где можно определить конфигурационный код и код операций билда.

Последнее замкнутое выражение выглядит как очередной блок операции билда, и мы ожидаем что вывод его сообщения будет последним, но не первым. Оказывается замыкание, добавленное к имени задачи без оператора сдвиг влево совсем не добавляет новую операцию. Вместо этого добавился блок конфигурации. Конфигурационный блок задачи выполняется во время конфигурационной фазы жизненного цикла Gradle, которая предшествует фазе выполнения, во время которой выполняются операции задачи.

Каждый раз, когда Gradle запускает билд, процесс проходит через три фазы жизненного цикла: инициализация, конфигурация и выполнение. Выполнение — фаза, во время которой задачи билда выполняются в порядке, указанном в настройках их зависимостей. Конфигурация — фаза в которой объекты задачи собираются во внутреннюю объектную модель, обычно называемую направленным ациклическим графом. Инициализация — фаза, в которой Gradle принимает решение, какие объекты будут принимать участие в билде. Последняя фаза важна в многопроектных билдах.

Замыкания конфигурации аддитивны точно так же, как и замыкания операций. Поэтому мы можем написать код файла билда для предыдущего примера способом приведенным ниже, при этом результат выполнения будет тот же, что и раньше:

Gradle, прежде чем выполнить билд, создаёт его внутреннюю объектную модель. Каждая задача, которую вы объявляете, в действительности, становится объектом-задачей в пределах всего проекта билда. У объекта-задачи, как и у любого другого объекта, есть свойства и методы. И ещё мы можем управлять типом каждого объекта-задачи, обращаясь к функциональности, определённой в нём.

По умолчанию, каждой новой задаче присваивается тип DefaultTask. Подобно тому, как каждый класс наследуется от Object в Java, в Gradle каждая задача наследуется от данного типа — даже те задачи, которые расширяют возможности DefaultTask путём создания нового типа. На самом деле, DefaultTask-задачи не делают ничего специфичного, вроде компиляции кода или копирования файлов. Однако они содержат функционал, который требуется для взаимодействия с программной моделью проекта Gradle. Рассмотрим методы и свойства, которые имеет каждая задача в Gradle.

Configuring the Dependency Configurations of Our Integration Tests

When we configured the source and resource directories of our integration tests, we created a source set that created two new dependency configurations: integrationTestCompile and integrationTestRuntime. The problem is that these configurations do not contain the dependencies of our unit tests.

We could solve this problem by adding the required dependencies to these configurations, but we won’t do that because adding duplicate configuration is an awful idea. Instead we will configure these dependency configurations by following these steps:

Ensure that the integrationTestCompile configuration contains the dependencies that are required to compile our unit tests.
Ensure that the integrationTestRuntime configuration contains the dependencies that are required to run our unit tests.

We can make these changes by using the configurations build script block. In other words, we must add the following code to our build.gradle file between the sourceSets and the dependencies build script blocks:

configurations {
    integrationTestCompile.extendsFrom testCompile
    integrationTestRuntime.extendsFrom testRuntime
}

Additional Reading:

Gradle DSL Reference: ConfigurationContainer
Gradle DSL Reference: Configuration

We can now add dependencies to these configurations. For example, if we want to use in our integration tests, we have to add the assertj-core dependency to the integrationTestCompile configuration. After we have done this, the dependencies build script block found from our build.gradle file looks as follows:

dependencies {
    compile 'log4j:log4j:1.2.17'
    testCompile 'junit:junit:4.11'
    integrationTestCompile 'org.assertj:assertj-core:3.0.0'
}

Additional Reading:

Getting Started With Gradle: Dependency Management

Our next step is to create the task that runs our integration tests. Let’s find out how we can do that.

Операция задачи (Task Action)

Выполнение задачи не произведёт никакого результата, поскольку мы не присвоили ей ни одной операции (action). Операцию можно присвоить используя оператор сдвиг влево. Перепишем пример:

Операторы, такие как << («сдвиг влево» из Java), могут быть перегружены в Groovy для изменения поведения в зависимости от объектов с которыми они работают. В данном случае << перегружен в Gradle для добавления блока кода в список операций, которые выполняет задача. Сдвиг влево является эквивалентом метода doLast(), который мы рассмотрим ниже.

Теперь у нас есть гибкая возможность добавления кода операции аддитивным способом, ссылаясь на объект задачи, который мы создали. Пример последовательного добавления операций задачи по одной:

Сначала мы объявили задачу, затем добавили первую операцию с методом print, следом добавили вторую операцию с методом println. Результат будет таким же.

Откуда берутся задачи

До настоящего момента мы создавали задачи путём непосредственного написания кода в билд-скриптах Gradle, либо в директории buildSrc в виде кода Groovy. Такой подход хорош для изучения задач, так как даёт подробный обзор всех их особенностей. Всё же, большинство задач, которые вы будете использовать, не будут написаны вами. Они будут импортироваться из внешних модулей.

В простейшем примере сборки консольного приложения HelloWorld на Java, файл билда выглядит следующим образом:

Применив модуль Java, билд-скрипт автоматически наследует набор задач, код которых вам не виден. Вы можете изменять поведение наследованных задач в блоках конфигурации, либо используя рассмотренные выше методы doFirst() и doLast(), для которых вам придётся писать код. Ключевой стратегией Gradle являются широкие возможности для расширения при малой сложности. Gradle предлагает вам большой набор функциональности посредством задач, подробности реализации которых вам не нужно знать, которые вы запускаете используя Gradle DSL (DSL — Domain Specific Language), а не множество запутанных инструкций кода Groovy.

Кроме того, в Gradle есть несколько встроенных задач, таких как tasks и properties. Такие задачи не импортируются из модулей или вашего кода. Они являются стандартом Gradle DSL.

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

Что может делать Gradle

Теперь, когда Gradle установлен, посмотрим, что он может делать. Прежде, чем вы создадите
build.gradle для проекта, выможете проверить, какие доступны задачи:

Вы должны увидеть список доступных задач. Если вы запустите Gradle в каталоге,
в котором нет ещё файла build.gradle, то увидите несколько
самых элементарных задач:

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

Говоря о добавлении плагинов, в следующей части урока вы добавите плагин, который отвечает
за базовую функциональность сборки Java-проектов.

10 ответов

Лучший ответ

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

Radim
22 Май 2014 в 06:02

В моем случае проблема заключалась в несоответствии версии Gradle. Я установил Gradle на Mac, используя

И получил последний градиент, который был 7.0

Однако, когда я клонировал репо проекта и выполнил gradle taks, он потерпел неудачу с ошибкой ниже

Файл build.gradle мне показался вполне нормальным, поскольку он имеет обычные зависимости

Мне потребовалось время, чтобы понять, что проблема в несоответствии версии. Gradle не может найти метод compile (), потому что я использовал gradle 7.0 в моем bash.

И проект должен был запускаться с gradle 4.8 (на самом деле должна была использоваться оболочка gradle, но это ломало еще одну интересную проблему (Если интересно, следуйте https://stackoverflow.com/a/67839118/1503163, чтобы узнать подробности)

Причина сбоя в компиляции заключается в том, что конфигурации компиляции , времени выполнения , testCompile и testRuntime , представленные Java плагин устарел с Gradle 4.10 и был окончательно удален в Gradle 7.0.

Итак, чтобы решить проблему, мне пришлось установить более раннюю версию gradle. Если вы хотите управлять несколькими версиями gradle, используйте https://sdkman.io/ (ранее известный как gvm)

Установка на macOs / linux так же проста, как выполнение ниже

После использования

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

(в текущей оболочке по умолчанию будет выбрано 4.8) (если он уже установлен, этого достаточно для переключения между версией gradle)

И теперь build.gradle смог скомпилировать и выполнить задачу.

Sanjay Bharwani
4 Июн 2021 в 14:49

Для записи: я случайно включил Автономную работу в разделе Настройки -> Сборка, выполнение, развертывание -> Gradle -> снимите флажок Автономная работа , но сообщение об ошибке вводило в заблуждение

longi
2 Дек 2019 в 10:56

В моем случае мне пришлось удалить некоторые файлы, которые были созданы gradle в какой-то момент моего исследования, чтобы все работало. Итак, очистка после испорченной ошибки, а затем все прошло нормально …

Если вы столкнулись с этой проблемой в проекте git, выполните и удалите неотредактированные файлы. (Для меня у была проблема с ).

: 5.1.1

dr0i
22 Янв 2019 в 14:54

Неверный файл Gradle. Правый — build.gradle в папке «app».

letanthang
28 Мар 2018 в 02:03

Надеюсь, что шаги ниже помогут

Добавьте зависимость к вашему уровню проекта build.gradle:

Добавьте плагин в build.gradle на уровне приложения :

на уровне приложения build.gradle:

parkerfath
3 Май 2017 в 04:31

В моем случае все операторы каким-то образом расположены в одной строке. разделение их на отдельные строки устранило проблему.

Rohit Mandiwal
25 Янв 2017 в 01:34

Обратите внимание, что конфигурации , , и , представленные подключаемым модулем Java, устарели с момента появления (август 27, 2018) и были окончательно удалены в 9 апреля 2021 г.). Вышеупомянутые конфигурации следует заменить на , , и соответственно

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

ashelkov
13 Апр 2021 в 17:10

— это , который обычно вводится подключаемым модулем (скорее всего, подключаемым модулем java). Подробные сведения о конфигурациях см. В руководстве пользователя gradle. На данный момент добавление java-плагина поверх вашего скрипта сборки должно помочь:

111

Rene Groeschke
22 Май 2014 в 07:55

Убедитесь, что вы редактируете правильный файл . Я получил эту ошибку при редактировании , а не .

173

Shashank Agrawal
21 Авг 2017 в 08:22

Creating the Task That Runs Our Integration Tests

We can create the task that runs our integration tests by following these steps:

Create a new task called integrationTest and set its type to Test.
Configure the location of the compiled test classes.
Configure the classpath that is used when our integration tests are run.

We can create and configure the integrationTest task by adding the following code to our build.gradle file:

task integrationTest(type: Test) {
    testClassesDirs = sourceSets.integrationTest.output.classesDirs
    classpath = sourceSets.integrationTest.runtimeClasspath
}

that Gradle skips tasks whose input and output are up to date. If you want to ensure that your integration tests are run every time when you run the integrationTest task, you have to tell Gradle that the outputs of the integrationTest task should always be considered out of date.

A Gradle task has a property called outputs, and the type of this property is TaskOutputs. If you want that the outputs of the integrationTest task are always considered out of date, you have to ensure that the upToDateWhen() method of the TaskOutputs interface always returns false. After you have done this, the declaration of the integrationTest task looks as follows:

task integrationTest(type: Test) {
    testClassesDirs = sourceSets.integrationTest.output.classesDirs
    classpath = sourceSets.integrationTest.runtimeClasspath
    outputs.upToDateWhen { false }
}

Additional Reading:

Gradle DSL Reference: Task

We have created the task that runs our integration tests, but the problem is this task is not invoked during our build. Because want to include it in our build, we have to follow these steps:

Ensure that our integration tests are run before the check task and that the check task fails the build if there are failing integration tests.
Ensure that our unit tests are run before our integration tests. This guarantees that our unit tests are run even if our integration tests fails.

We can do these configuration changes by adding the following lines to our build.gradle file:

check.dependsOn integrationTest
integrationTest.mustRunAfter test

Additional Reading:

We are done! Let’s move on and find out how we can run our tests.

3 ответа

Лучший ответ

Каждый проект содержит . Обычно он содержит для всех . Что бы ни было включено в этот , это повлияет на все .

Пример:

Все имеют определенный файл . Что бы ни было включено в этот файл , это повлияет только на , который включен.

Пример:

hrskrs
18 Янв 2016 в 07:08

Относительно отношения двух файлов hrskrs дал очень четкое объяснение ， Я сделаю некоторые дополнения по этому поводу.

Если в вашем проекте есть только один модуль (например, app ), преимущество верхнего build.gradle (Project: My-app) не очень очевидно. потому что вы можете настроить все в build.gradle (Module: app) о модуле и изменить только один файл при обновлении в следующие дни。

Но если в вашем проекте 5 модулей, и случилось так, что они имеют одинаковую зависимость A , если вы не используете верхний build.gradle (Project: My-app) , вы необходимо сохранить 5 файлов в последующие дни.

Кстати, build.gradle (Module: app) может перезаписать build.gradle (Project: My-app) .

Такой дизайн может улучшить ремонтопригодность приложения.

shusheng007
23 Мар 2018 в 08:52

Это немного сбивает с толку, потому что Android Studio по умолчанию показывает оба файла рядом друг с другом (при использовании представления Android).

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

Файл (Project: MyApplication) находится в корневой папке проекта, и его настройки конфигурации применяются ко всем модулям в проекте. Модуль — это обособленная часть более крупного проекта. В многомодульном проекте эти модули выполняют свои собственные задачи, но работают вместе, чтобы сформировать весь проект. В большинстве проектов Android есть только один модуль — модуль приложения.

Файл (Module: app) здесь находится в папке . Его настройки сборки применяются только к модулю приложения. Если бы был другой модуль, то у этого модуля тоже был бы свой собственный файл . В качестве примера я сделал проект библиотеки с тремя модулями: модуль библиотеки, модуль демонстрационного приложения. , и еще один модуль приложения, который я планирую использовать для тестирования. У каждого из них есть свои файлы , которые я могу настроить.

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

Дальнейшее чтение

Настройте свою сборку (документация Android — очень удобочитаема и полезна)
Введение в многопроектные сборки (документация Gradle)

Harsha
27 Апр 2018 в 09:41

Configuring the Source and Resource Directories of Our Integration Tests

We can add new source and resource directories to our Gradle build by using the sourceSets build script block. Armed with this information, we can configure the source and resource directories of our integration tests by following these steps:

Create a new source set called integrationTest.
Ensure that the output of the main and test source sets is added to the compile time classpath.
Ensure that the output of the main and test source sets is added to the runtime classpath.
Set the source directory of our integration tests to src/integration-test/java.
Set the resource directory of our integration tests to src/integration-test/resources.

When we are done, our build.gradle file should have the following sourceSets build script block right after the repositories build script block:

sourceSets {
    integrationTest {
        java {
            compileClasspath += main.output + test.output
            runtimeClasspath += main.output + test.output
            srcDir file('src/integration-test/java')
        }
        resources.srcDir file('src/integration-test/resources')
    }
}

Sometimes you might not want that integration tests depend from unit tests. For example, you might want to use two different implementations of the same API. If this is the case, . Also, I recommend that you take a look at that describes the difference between files() and file() methods.

Additional Reading:

Gradle DSL Reference: SourceSetOutput

When we run the command: gradle properties at the command prompt, we will see a long list of the project’s properties. The properties that are relevant for this blog posts are shown in the following:

> gradle properties
:properties

------------------------------------------------------------
Root project
------------------------------------------------------------
configurations: 

sourceSets: 
sources: 

BUILD SUCCESSFUL

Total time: 3.34 secs

As we can see, we added a new source and resource directories to our Gradle build. The interesting this is that when we created a new source set, the Java plugin added two new dependency configurations to our build:

The integrationTestCompile configuration is used to declare the dependencies that are required when our integration tests are compiled.
The integrationTestRuntime configuration is used to declare the dependencies that are required to run our integration tests. This configuration contains all dependencies that are added to the integrationTestCompile configuration.

Additional Reading:

Gradle User Guide: 22.5 Java Plugin — Dependency Management

Let’s move and find out what kind of configuration changes we have to make before these dependency configurations are useful to us.

Running Our Tests

We have now created a new task that runs our integration tests and integrated that task with our Gradle build. We are finally ready to run our unit and integration tests. The requirements of our Gradle build states that:

We must be able to run our only unit tests.
We must be able to run only integration tests.
We must be able to run all tests.

Let’s go through these requirements one by one.

First, if we want to run only unit tests, we can use one of these two options:

We can run our unit tests by running the command: gradle clean test at the command prompt.
We can run our build and exclude integration tests by running the command: gradle clean build -x integrationTest at the command prompt.

Second, if we want to run only integration tests, we can choose one of the following options:

We can run our integration tests by running the command: gradle clean integrationTest at the command prompt.
We can run our build and exclude unit tests by running the command: gradle clean build -x test at the command prompt.

Third, if we want to run all tests, we can use one of these two options:

We run our unit and integration tests by running the command: gradle clean test integrationTest at the command prompt.
We can run our build by running the command: gradle clean build at the command prompt.

Additional Reading:

Gradle User Guide: 11.2 Excluding tasks

When we run our tests, Gradle creates the HTML reports of our unit and integration tests to the following directories:

The build/reports/tests/integrationTest directory contains the HTML report that contains the test results of our integration tests.
The build/reports/tests/test directory contains the HTML report that contains the test results of our unit tests.

Let’s summarize what we learned from this blog post.

Запуск проекта

Gradle позволяет легко запускать проект из командной строки. Просто используйте команду gradlew, указав целевую платформу и команду запуска для этой
платформы.

Запуск desktop проекта

Эта команда скомпилирует основной и desktop проект, и затем запустит desktop стартер. Рабочей директорией является assets директория Android проекта!

Запуск Android проекта

Эта задача создаст debug APK вашего приложения, установит его на первый подключенный эмулятор или устройство и запустит основную Activity. Процесс
разделен на две задачи, потому что Android Gradle плагин позволяет создавать несколько версий вашего приложения (например: debug, release, …). Вы
можете найти более подробную информацию на сайте Android Gradle Plugin.

Запуск iOS проекта

Первые две команды запустят ваше приложение на эмуляторе iPhone или iPad, последняя команда запустит ios проект на подключенном устройстве, при условии,
что оно готово. Пожалуйста, обратитесь к документации Apple о том, как подготовить устройство

Обратите внимание, что

Время компиляции

В первый раз, когда вы запустите ваш iOS проект, компиляция займет много времени. Время компиляции значительно снизится при последующих запусках

Команда приведет к запуску приложения в GWT Super Dev режиме, который компилирует Java код в JavaScript и позволяет отлаживать Java код прямо в
браузере. Если вы видите сообщение в вашей оболочке, откройте браузер и перейдите по этому адресу.
Перетащите «Dev Mode On» закладку на свою панель закладок браузера. Затем откройте http://localhost:8080/html.
Это ваше работающее приложение в браузере! При изменении любого вашего Java кода в основном проекте, просто нажмите на закладку, затем нажмите кнопку
«Compile». Изменения вступят в силу в течение нескольких секунд. Если вы измените ваши assets, то вы должны перезагрузить сервер командой выше.