Pull to refresh

Comments 3

На мой вкус для плагинов лучше писать полноценные интеграционные тесты. Это легко делается с помощью GradleRunner:

        val buildResult = GradleRunner.create()
            .withProjectDir(tempProjectPath.toFile())
            .withPluginClasspath()
            .withArguments("build", "--stacktrace")
            .build()

Вот пример интеграционного теста для Gradle плагина (кодогенерация), который ищет подготовленные тесткейсы в ресурсах проекта, копирует их во временную директорию, и выполняет полноценную сборку gradle build с помощью GradleRunner. Затем он сравнивает результат сборки с эталонным результатом в ресурсах проекта.

Есть только один минус у этого подхода - GradleRunner стартует gradle демон, что очень не быстро. Соответственно первый тесткейс у меня выполняется порядка 40 секунд, последующие по 1-2 секунды.

Спасибо! Это следующий этап после тестирования с помощью Composite builds :) Выглядит элегантно и позволяет делать более гибкие проверки результата тестирования. Обязательно попробую в своих проектах.

Project project = Mockito.spy(Project.class);    
Mockito.when(project.getExtensions()).thenReturn(...);
Mockito.when(project. ...).thenReturn(...);

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

Как правильно предложили выше, надо писать инт тесты. Юнит тесты - это если у вас там есть какая-то логика, которую в изоляции от внешних зависимостей можно протестировать.

Sign up to leave a comment.

Articles