Maven и Gradle — бесплатный тест онлайн

Вопрос 1 из 30

Какое замечание о сопровождении или производительности темы «Воспроизводимая сборка» в разделе «Maven и Gradle» справедливо?

Очистка кэша повышает доверие, но ежедневная полная загрузка замедляет непрерывную интеграцию; ключ кэша должен зависеть от точных входов. Жёсткая фиксация повышает повторяемость, но требует автоматического процесса безопасного обновления и проверки уязвимостей. Полный сквозной тест повышает доверие, но сочетание узких контрактных и нескольких сквозных сценариев быстрее локализует дефект. Широкая проверка повышает доверие, но медленнее и сложнее диагностируется; нужна разумная пирамида, а не один вид тестов. Жёсткая фиксация повышает повторяемость, но не требует автоматического процесса безопасного обновления и проверки уязвимостей.

Вопрос 2 из 30

В каком дополнительном сценарии вывод о теме «Воспроизводимая сборка» в разделе «Maven и Gradle» может оказаться неверным?

# Минимальный пример
jar --create --file app.jar -C build/classes .
# manifest содержит Build-Time: ${now} и путь рабочего каталога

Интеграционный тест должен изолировать данные и не зависеть от порядка запуска. SNAPSHOT и динамические версии нарушают повторяемость, даже если имя зависимости не менялось. Повторная проверка на сервере обязательна, даже если клиент уже валидировал поля. Команда mvn clean package сначала выполняет отдельный жизненный цикл clean, удаляя каталог target, а затем проходит основной жизненный цикл до package. Один логический сценарий может содержать несколько связанных проверок, если они описывают один результат.

Вопрос 3 из 30

Какой риск для воспроизводимости сборки создаёт этот фрагмент POM?

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
</plugin>

Задача Gradle читает переменную окружения, но не объявляет её входом, поэтому кэш может вернуть неверный результат. Maven обычно выбирает ближайшее определение версии, поэтому порядок графа может дать неожиданную библиотеку. Если версия плагина не зафиксирована, поведение может измениться после обновления родительского POM или окружения. Отдельное пустое хранилище Maven исключает случайные артефакты из ~/.m2 и выявляет незадекларированную либо недоступную зависимость. Запись текущего времени и абсолютного пути в JAR делает хеш артефакта разным при каждом запуске.

Вопрос 4 из 30

Как лучше исправить или прояснить поведение темы «Воспроизводимая сборка» в разделе «Maven и Gradle»?

# Фрагмент на ревью
jar --create --file app.jar -C build/classes .
# manifest содержит Build-Time: ${now} и путь рабочего каталога

Зафиксировать версии плагинов в pluginManagement и проверять итоговый effective POM. Объявить inputs.property или provider и выходы задачи, а действие сделать детерминированным. Запустить в чистом контейнере с отдельным хранилищем зависимостей и запретом сетевых незадекларированных шагов. Фиксировать набор инструментов и версии зависимостей, задавать стабильный порядок файлов и воспроизводимую временную отметку. Зафиксировать версии в dependencyManagement или платформе и анализировать дерево зависимостей.

Вопрос 5 из 30

Какое изменение сделает код по теме «Тестирование и диагностика» в разделе «Maven и Gradle» надёжнее?

# Фрагмент на ревью
rm -rf /tmp/empty-m2
mvn -Dmaven.repo.local=/tmp/empty-m2 verify

Привязывать генерацию и проверки к подходящей фазе, не запуская вложенный Maven из плагина. Объявить inputs.property или provider и выходы задачи, а действие сделать детерминированным. Зафиксировать версии в dependencyManagement или платформе и анализировать дерево зависимостей. Запустить в чистом контейнере с отдельным хранилищем зависимостей и запретом сетевых незадекларированных шагов. Фиксировать набор инструментов и версии зависимостей, задавать стабильный порядок файлов и воспроизводимую временную отметку.

Вопрос 6 из 30

Какое изменение сделает код по теме «Зависимости» в разделе «Maven и Gradle» надёжнее?

# Фрагмент на ревью
mvn dependency:tree
# lib-a -> json:1.0, lib-b -> helper -> json:2.0

Привязывать генерацию и проверки к подходящей фазе, не запуская вложенный Maven из плагина. Зафиксировать версии в dependencyManagement или платформе и анализировать дерево зависимостей. Запустить в чистом контейнере с отдельным хранилищем зависимостей и запретом сетевых незадекларированных шагов. Фиксировать набор инструментов и версии зависимостей, задавать стабильный порядок файлов и воспроизводимую временную отметку. Зафиксировать версии плагинов в pluginManagement и проверять итоговый effective POM.

Вопрос 7 из 30

Каков точный результат выполнения или компиляции фрагмента из раздела «Maven и Gradle» по теме «Тестирование и диагностика»?

rm -rf /tmp/empty-m2
mvn -Dmaven.repo.local=/tmp/empty-m2 verify

Maven обычно выбирает ближайшее определение версии, поэтому порядок графа может дать неожиданную библиотеку. Задача Gradle читает переменную окружения, но не объявляет её входом, поэтому кэш может вернуть неверный результат. Отдельное пустое хранилище Maven исключает случайные артефакты из ~/.m2 и выявляет незадекларированную либо недоступную зависимость. Запись текущего времени и абсолютного пути в JAR делает хеш артефакта разным при каждом запуске. Команда mvn package включает фазы compile и test, если тесты явно не отключены.

Вопрос 8 из 30

Как точнее оценить пользу и цену решения по теме «Жизненный цикл» в разделе «Maven и Gradle»?

Плагин сокращает ручной код, но получает доступ к исходникам, секретам и машине сборки, поэтому его происхождение и версия должны быть проверены. Стандартный жизненный цикл делает сборку предсказуемой, но тяжёлые проверки надо распределять без нарушения локальной воспроизводимости. Жёсткая фиксация повышает повторяемость, но требует автоматического процесса безопасного обновления и проверки уязвимостей. Очистка кэша повышает доверие, но ежедневная полная загрузка замедляет непрерывную интеграцию; ключ кэша должен зависеть от точных входов. Централизованная платформа уменьшает дрейф, но обновление крупного набора требует совместного тестирования.

Вопрос 9 из 30

Какой диагноз для кода по теме «Воспроизводимая сборка» в разделе «Maven и Gradle» будет точным?

jar --create --file app.jar -C build/classes .
# manifest содержит Build-Time: ${now} и путь рабочего каталога

Команда mvn package включает фазы compile и test, если тесты явно не отключены. Запись текущего времени и абсолютного пути в JAR делает хеш артефакта разным при каждом запуске. Отдельное пустое хранилище Maven исключает случайные артефакты из ~/.m2 и выявляет незадекларированную либо недоступную зависимость. Если версия плагина не зафиксирована, поведение может измениться после обновления родительского POM или окружения. Maven обычно выбирает ближайшее определение версии, поэтому порядок графа может дать неожиданную библиотеку.

Вопрос 10 из 30

Какая правка точнее всего устраняет причину проблемы по теме «Жизненный цикл» в разделе «Maven и Gradle»?

# Фрагмент на ревью
# кастомный плагин привязан к фазе generate-sources
# внутри execute() плагин вызывает через ProcessBuilder
# отдельный процесс: mvn -f codegen-module/pom.xml package

Объявить inputs.property или provider и выходы задачи, а действие сделать детерминированным. Привязывать генерацию и проверки к подходящей фазе, не запуская вложенный Maven из плагина. Запустить в чистом контейнере с отдельным хранилищем зависимостей и запретом сетевых незадекларированных шагов. Зафиксировать версии в dependencyManagement или платформе и анализировать дерево зависимостей. Зафиксировать версии плагинов в pluginManagement и проверять итоговый effective POM.

Вопрос 11 из 30

Почему кэш Gradle может вернуть для этой задачи устаревший результат?

tasks.register("generateConfig") {
    outputs.file(layout.buildDirectory.file("config.txt"))
    doLast { output.writeText(System.getenv("MODE")) }
}

Maven обычно выбирает ближайшее определение версии, поэтому порядок графа может дать неожиданную библиотеку. Если версия плагина не зафиксирована, поведение может измениться после обновления родительского POM или окружения. Задача Gradle читает переменную окружения, но не объявляет её входом, поэтому кэш может вернуть неверный результат. Команда mvn package включает фазы compile и test, если тесты явно не отключены. Отдельное пустое хранилище Maven исключает случайные артефакты из ~/.m2 и выявляет незадекларированную либо недоступную зависимость.

Вопрос 12 из 30

Какое правило Java действует для темы «Производительность и эксплуатация» в разделе «Maven и Gradle»?

Инкрементальная сборка и кэш работают только при объявленных входах и выходах и отсутствии скрытых побочных эффектов. Maven выполняет фазы выбранного жизненного цикла до указанной включительно; Gradle строит граф задач и запускает зависимости. Конструкторная инъекция делает обязательные зависимости явными и позволяет создать полностью инициализированный объект. Сборку следует проверять с пустым локальным кэшем, на поддерживаемой JDK и с анализом графа задач/зависимостей. Разрешение транзитивных зависимостей требует контроля версий, областей видимости и конфликтов графа.

Вопрос 13 из 30

Как лучше исправить или прояснить поведение темы «Плагины» в разделе «Maven и Gradle»?

<!-- Фрагмент на ревью -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
</plugin>

Объявить inputs.property или provider и выходы задачи, а действие сделать детерминированным. Фиксировать набор инструментов и версии зависимостей, задавать стабильный порядок файлов и воспроизводимую временную отметку. Зафиксировать версии плагинов в pluginManagement и проверять итоговый effective POM. Зафиксировать версии в dependencyManagement или платформе и анализировать дерево зависимостей. Привязывать генерацию и проверки к подходящей фазе, не запуская вложенный Maven из плагина.

Вопрос 14 из 30

Какой контракт языка или библиотеки точнее всего описывает тему «Тестирование и диагностика» в разделе «Maven и Gradle»?

Одинаковые исходники и зафиксированное окружение должны давать эквивалентный артефакт без зависимости от времени и локальной машины. Сборку следует проверять с пустым локальным кэшем, на поддерживаемой JDK и с анализом графа задач/зависимостей. Разрешение транзитивных зависимостей требует контроля версий, областей видимости и конфликтов графа. Инкрементальная сборка и кэш работают только при объявленных входах и выходах и отсутствии скрытых побочных эффектов. Maven выполняет фазы выбранного жизненного цикла до указанной включительно; Gradle строит граф задач и запускает зависимости.

Вопрос 15 из 30

Что важно учитывать при применении механизма «Тестирование и диагностика» из раздела «Maven и Gradle» в рабочем проекте?

Тонкий контроллер облегчает повторное использование кода, но у координации вызовов и политики ошибок всё равно должен быть явный владелец. Жёсткий лимит защищает процесс, но часть нагрузки получит явный отказ; повторять запрос можно только при безопасной семантике операции. Контейнер внедрения зависимостей упрощает связывание компонентов, но не должен превращать каждый объект данных и каждую функцию в глобальный компонент. Очистка кэша повышает доверие, но ежедневная полная загрузка ускоряет непрерывную интеграцию; ключ кэша должен зависеть от точных входов. Очистка кэша повышает доверие, но ежедневная полная загрузка замедляет непрерывную интеграцию; ключ кэша должен зависеть от точных входов.

Вопрос 16 из 30

Как Maven разрешит показанный конфликт версий зависимостей?

mvn dependency:tree
# lib-a -> json:1.0, lib-b -> helper -> json:2.0

Отдельное пустое хранилище Maven исключает случайные артефакты из ~/.m2 и выявляет незадекларированную либо недоступную зависимость. Задача Gradle читает переменную окружения, но не объявляет её входом, поэтому кэш может вернуть неверный результат. Локатор сервисов скрывает зависимости и переносит ошибку отсутствующего компонента в произвольный вызов во время выполнения. Будет выбрана json:1.0 как более близкая прямая зависимость, а транзитивная json:2.0 не попадёт в разрешённый граф. Запись текущего времени и абсолютного пути в JAR делает хеш артефакта разным при каждом запуске.

Вопрос 17 из 30

Какой инженерный компромисс характерен для темы «Зависимости» в разделе «Maven и Gradle»?

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

Вопрос 18 из 30

На какое правило следует опираться при разборе темы «Воспроизводимая сборка» в разделе «Maven и Gradle»?

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

Вопрос 19 из 30

Какой риск проявится при параллельном выполнении этих двух задач?

def shared = layout.projectDirectory.file("generated/config.txt")

tasks.register("generateA") {
    doLast { shared.asFile.text = "A" }
}
tasks.register("generateB") {
    doLast { shared.asFile.text = "B" }
}

// ./gradlew generateA generateB --parallel

Флаг --parallel запрещает запись файлов из задач. Параллельность влияет только на скачивание зависимостей и не меняет выполнение задач. Параллельная сборка выявит гонку: две независимые задачи пишут общий файл, поэтому результат недетерминирован. Gradle гарантирует выполнение generateA раньше generateB по алфавиту. Обе записи будут автоматически объединены в строку "AB".

Вопрос 20 из 30

Что нужно отдельно проверить на границе контракта «Жизненный цикл» в разделе «Maven и Gradle»?

# Минимальный пример
mvn package
# проект содержит unit-тесты и jar packaging

Необязательная зависимость Maven не становится обычной транзитивной зависимостью для потребителя. Плагин Gradle может добавлять задачи лениво; чтение значений на этапе конфигурации ухудшает работу кэша конфигурации. Команда mvn clean package сначала выполняет отдельный жизненный цикл clean, удаляя каталог target, а затем проходит основной жизненный цикл до package. SNAPSHOT и динамические версии нарушают повторяемость, даже если имя зависимости не менялось. Gradle Build Scan полезен для диагностики, но передача данных внешней службе должна соответствовать политике проекта.

Вопрос 21 из 30

Какая правка точнее всего устраняет причину проблемы по теме «Производительность и эксплуатация» в разделе «Maven и Gradle»?

// Фрагмент на ревью
tasks.register("generateConfig") {
    outputs.file(layout.buildDirectory.file("config.txt"))
    doLast { output.writeText(System.getenv("MODE")) }
}

Запустить в чистом контейнере с отдельным хранилищем зависимостей и запретом сетевых незадекларированных шагов. Зафиксировать версии плагинов в pluginManagement и проверять итоговый effective POM. Зафиксировать версии в dependencyManagement или платформе и анализировать дерево зависимостей. Выдавать каждому тесту собственное пространство имён, транзакцию или контейнер и гарантированно очищать ресурсы. Объявить inputs.property или provider и выходы задачи, а действие сделать детерминированным.

Вопрос 22 из 30

Какое ограничение механизма «Зависимости» нельзя упускать при работе с разделом «Maven и Gradle»?

# Минимальный пример
mvn dependency:tree
# lib-a -> json:1.0, lib-b -> helper -> json:2.0

Необязательная зависимость Maven не становится обычной транзитивной зависимостью для потребителя. Повторная проверка на сервере обязательна, даже если клиент уже валидировал поля. Интеграционный тест должен изолировать данные и не зависеть от порядка запуска. Идемпотентность метода определяется эффектом и контрактом, а не только названием маршрута. Команда mvn clean package сначала выполняет отдельный жизненный цикл clean, удаляя каталог target, а затем проходит основной жизненный цикл до package.

Вопрос 23 из 30

Какой диагноз для кода по теме «Жизненный цикл» в разделе «Maven и Gradle» будет точным?

mvn package
# проект содержит unit-тесты и jar packaging

Задача Gradle читает переменную окружения, но не объявляет её входом, поэтому кэш может вернуть неверный результат. Maven обычно выбирает ближайшее определение версии, поэтому порядок графа может дать неожиданную библиотеку. Команда mvn package включает фазы compile и test, если тесты явно не отключены. Запись текущего времени и абсолютного пути в JAR делает хеш артефакта разным при каждом запуске. Если версия плагина не зафиксирована, поведение может измениться после обновления родительского POM или окружения.

Вопрос 24 из 30

Какое утверждение о механизме «Зависимости» верно в контексте раздела «Maven и Gradle»?

Разрешение транзитивных зависимостей не требует контроля версий, областей видимости и конфликтов графа. Журналы сборщика мусора дают временную линию сборок, причин, пауз, размеров областей и изменения объёма живых объектов. Синтаксическая валидация DTO и предметные инварианты решают разные задачи и должны давать разные ошибки. Интеграционный тест проверяет совместимость нескольких реальных компонентов и жизненный цикл инфраструктуры. Разрешение транзитивных зависимостей требует контроля версий, областей видимости и конфликтов графа.

Вопрос 25 из 30

Какой граничный случай особенно важен для темы «Плагины» в разделе «Maven и Gradle»?

<!-- Минимальный пример -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
</plugin>

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

Вопрос 26 из 30

Как точнее оценить пользу и цену решения по теме «Производительность и эксплуатация» в разделе «Maven и Gradle»?

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

Вопрос 27 из 30

На какое правило следует опираться при разборе темы «Жизненный цикл» в разделе «Maven и Gradle»?

Плагин выполняет логику сборки; его версия тоже является частью воспроизводимого окружения. Maven выполняет фазы выбранного жизненного цикла до указанной включительно; Gradle строит граф задач и запускает зависимости. Разрешение транзитивных зависимостей требует контроля версий, областей видимости и конфликтов графа. Сборку следует проверять с пустым локальным кэшем, на поддерживаемой JDK и с анализом графа задач/зависимостей. Одинаковые исходники и зафиксированное окружение должны давать эквивалентный артефакт без зависимости от времени и локальной машины.

Вопрос 28 из 30

Какой контракт языка или библиотеки точнее всего описывает тему «Плагины» в разделе «Maven и Gradle»?

Тестовый набор должен быть воспроизводимым, параллельным только при изоляции и иметь отдельный слой нагрузочных измерений. Синтаксическая валидация DTO и предметные инварианты решают разные задачи и должны давать разные ошибки. HTTP-слой переводит протокол в предметные команды и ответы, не смешивая коды транспорта с ядром модели. Плагин выполняет логику сборки; его версия тоже является частью воспроизводимого окружения. Хороший тест ясно разделяет подготовку, действие и проверку одного поведения, не скрывая значимые данные.

Вопрос 29 из 30

Как точнее оценить пользу и цену решения по теме «Плагины» в разделе «Maven и Gradle»?

Очистка кэша повышает доверие, но ежедневная полная загрузка замедляет непрерывную интеграцию; ключ кэша должен зависеть от точных входов. Ранняя валидация сокращает лишнюю работу, но правила, зависящие от состояния, нельзя надёжно вынести только в аннотации DTO. Жёсткий лимит защищает процесс, но часть нагрузки получит явный отказ; повторять запрос можно только при безопасной семантике операции. Плагин сокращает ручной код, но получает доступ к исходникам, секретам и машине сборки, поэтому его происхождение и версия должны быть проверены. Быстрый набор даёт частую обратную связь, но критические медленные проверки нельзя просто удалить — их выносят в подходящий этап конвейера.

Вопрос 30 из 30

Какое ограничение механизма «Тестирование и диагностика» нельзя упускать при работе с разделом «Maven и Gradle»?

# Минимальный пример
rm -rf /tmp/empty-m2
mvn -Dmaven.repo.local=/tmp/empty-m2 verify

Gradle Build Scan полезен для диагностики, но передача данных внешней службе должна соответствовать политике проекта. SNAPSHOT и динамические версии нарушают повторяемость, даже если имя зависимости не менялось. Необязательная зависимость Maven не становится обычной транзитивной зависимостью для потребителя. Плагин Gradle может добавлять задачи лениво; чтение значений на этапе конфигурации ухудшает работу кэша конфигурации. Параллельная сборка ускоряет независимые модули, но выявляет плагины, пишущие в общие файлы.