Как мы играли в тесты на Groovy и проиграли

В начале у меня будет один вопрос к тебе дорогой читатель. Кодил ли ты когда-нибудь unit тесты на Groovy ? Если твоя профессия андроид-разработчик, то вероятность этого крайне мала. И я с таким не сталкивался до проекта Альфы.

Давай представим, что ты приходишь на проект и видишь такой тест:

class InvestmentsInstrumentsRepositorySpec extends Specification {

    @ClassRule
    @Shared
    RxJavaRule rxJavaRule

    def service = Mock(InvestmentsInstrumentsService)
    def repository = new InvestmentsInstrumentsRepository(service)

    def 'should call service and return proper response'() {
        given:
            def expectedResponse = InvestmentsInstrumentsTestDataKt.getInvestmentsInstrumentsResponse()
        when:
            def observer = repository.getInstruments().test()
        then:
            1 * service.getInvestmentsInstruments() >> Single.just(expectedResponse)
            observer.assertValue(expectedResponse)
    }
}

Не буду таить, моя реакция была примерно такой:

Но давай пока оставим помидоры в стороне и дадим шанс такому тесту.

Если присмотреться, в целом, ничего страшного в нём нет. Это тест на репозиторий, который мокает зависимости и проверяет, что при вызове определённого метода, один раз дергается нужный метод мока. Причем тест выглядит довольно красиво, очень помогают метки given/when/then (чуть позже мы посмотрим за счёт чего это работает).

Вот как выглядит такой же тест на JUnit 5, для сравнения:

@ExtendWith(RxJavaExtension::class)
class InvestmentsInstrumentsRepositoryTest {

    private val service = mockk<InvestmentsInstrumentsService>()
    private val repository = InvestmentsInstrumentsRepository(service)

    @Test
    fun `should call service and return proper response`() {
        // given
        val expectedResponse = getInvestmentsInstrumentsResponse()
        every { service.getInvestmentsInstruments() } returns Single.just(expectedResponse)
        // when
        val observer = repository.getInstruments().test()
        // then
        verify(exactly = 1) { service.getInvestmentsInstruments() }
        observer.assertResult(expectedResponse)
    }
}

Пока можем заметить, что работа с метками given/when/then выглядит не так приятно, но давай пойдём дальше.

Для написания тестов на Groovy у нас используется библиотека Spock. Spock как тестовый движок использует JUnit, причём начиная с версии 2.x это уже JUnit 5. Однако в нашем случае мы пользовались той версией, которая использует JUnit 4.

А теперь вопрос — слышал ли ты про Data Driven Testing ? Если нет, то сейчас я покажу пример:

@Unroll
    def 'should call paymentsMediator startActivity'() {
        given:
            featureToggle.isDisabled(Feature.REDESIGN) >> REDESIGN_TOGGLE
            featureToggle.isDisabled(Feature.WIDGET_PAYMENT_HUB) >> PAYMENT_TOGGLE
        when:
            router.openPayScreen(expectedAccountNumber)
        then:
            1 * paymentsMediator.startActivity(*_) >> { activity, actualAccountNumber ->
                assert actualAccountNumber == expectedAccountNumber
            }
        where:
            REDESIGN_TOGGLE | PAYMENT_TOGGLE
            false           | true
            true            | false
            false           | false
    }

И ещё один пример:

@Unroll
    def 'should map unread count and reports to common items list'() {
        when:
            def actualMappedData = mapper.map(
                    AccountStatementsTestDataKt.getReportsListResponse(),
                    unreadCountResponse
            )
        then:
            actualMappedData == expectedMappedData
        where:
            unreadCountResponse                                          | expectedMappedData
            AccountStatementsTestDataKt.gerUnreadCountResponseWithZero() | AccountStatementsTestDataKt.getBaseItemsListWithZeroCount()
            AccountStatementsTestDataKt.gerUnreadCountResponse()         | AccountStatementsTestDataKt.getBaseItemsListWithOneCount()
    }

Такие тесты называются параметризованными. В блоке where: описываем параметры и тест будет запускаться с каждым из этих параметров.

Такой подход позволяет сильно экономить на количестве кода, так как нам не надо описывать несколько однотипных тестов, чтобы проверить все условия. Такие тесты можно объединить в один параметризованный тест. И в Споке, как ты видишь, это выглядит довольно красиво. Если интересно можешь глянуть как такое делать в голом JUnit 4 или JUnit 5. Спойлер — это будет выглядеть более громоздко :

object ProvideAccountStatusNotClosed : ArgumentsProvider {

        override fun provideArguments(context: ExtensionContext?): Stream<out Arguments> {
            return TestParamsUtils.getParams<BrokerageAccountStatusesResponse>(
                InvestmentsDocumentsTestData.createBrokerageAccountStatusOpenResponse(),
                InvestmentsDocumentsTestData.createBrokerageAccountStatusPendingResponse(),
                InvestmentsDocumentsTestData.createBrokerageAccountStatusErrorResponse(),
                InvestmentsDocumentsTestData.createBrokerageAccountStatusUnknownResponse(),
            )
        }
    }

    @ParameterizedTest
    @ArgumentsSource(ProvideAccountStatusNotClosed::class)
    fun `should load documents if brokerage account not closed`(expectedStatusResponse: BrokerageAccountStatusesResponse) {
        // when
        presenter.onViewCreated()
        // then
        verify(exactly = 1) { mapper.prepareDocModelsList(expectedDocsResponse) }
    }

Выглядит не так уж поэтично, согласись.

Давай еще учитывать факт, что показан один из самых простых кейсов. Это я еще не говорю об остальных проблемах, которые появляются когда мы захотим иметь несколько параметризованных тестов в одном тест классе. А также я не говорю о том, что в JUnit 4 с параметризованными тестами дела обстоят ещё хуже.

И ещё один небольшой факт, у нас сейчас на проекте 3 тысячи параметризованных тестов.

Но у тебя может возникнуть вопрос. «Вот автор только и делает, что нахваливает тесты на Groovy, в чём же он проиграл?»

Не торопись, сейчас я все расскажу, до этого я пытался объяснить, почему мы решили писать тесты на Groovy :)

Минус №1

Всё ли нормально в этом тесте ?

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

Не работает, в чем же дело? А дело в том, что в Groovy используется динамическая компиляция. Это одновременно и огромная сила, которая позволяет делать красивые тесты и одновременно огромное проклятье.

Но есть один workaround, мы можем поставить аннотацию @CompileStatic.

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

Проблема выше стреляет часто, даже у тех, кто уже привык писать тесты на Groovy. А теперь представь, первый день на проекте и тебя попросили написать тесты. Готов поспорить, что все возможные шишки будут собраны прежде, чем тест запустится. Да и я ещё ни разу на собесе не сталкивался с ситуацией когда кандидат говорил «Да вы что, у вас тесты на Groovy!! Как здорово, у меня как раз много опыта в таких тестах!» То есть такие тесты добавляют дополнительный порог вхождения в проект.

Минус №2

Когда мы хотим написать тест, где используется зависимость из Android (так называемый интеграционный тест) мы используем robolectric. Для Spock есть обвязка вокруг robolectric, которая называется electricspock.

Видишь проблемы в скриншоте ниже?

Последние актуальные коммиты 4 года назад и electricspock, в целом, выглядит заброшенным. Можно сказать, что это не супер большая проблема.

Но такое утверждение работает ровно до того момента, когда тебе понадобится обновить версию AGP (Android Gradle plugin). В нашем кейсе мы получили большое количество неработающих тестов, которые использовали electricspock. Проблема была зарыта глубоко и нам пришлось форкать electricspock и добавлять свои фиксы. Во-первых, это создает громадный bus factor, а во-вторых, это решение работает ровно до следующего раза, когда понадобится обновить AGP.

К тому же, чтобы доработать electricspock, надо сначала разобраться как работает сам Spock. Сейчас я покажу небольшой фрагмент кода оттуда ты поймешь насколько это нетривиальная задача. Не будем погружаться супер глубоко:

Начинается все с класса SpockTransform. То есть мы уже имеем дело с компиляторным плагином.

Внутри SpockTransform создается SpecParser, SpecRewriter, SpecAnnotator, которые работает с AST нашего теста. Также нам придется разобраться как работает Sputnik — JUnit runner для Spock тестов:

В целом ничего сложного, нужно всего лишь изучить как работает рантайм Spock и тогда можно спокойно фиксить проблемы electricspock:

Но от проблемы bus factor это не спасает слова совсем. Особенно если учитывать то, как быстро развивается Android, Gradle и AGP вместе с ними.

Итоги

В какой-то момент проблемы стали бить слишком больно. И мы приняли решение начать постепенный переход на другой фреймворк для тестирования, а именно Kotest, который зиждется на JUnit 5. Почему мы выбрали именно его и как начали миграцию, я опишу в отдельной статье. Однако не стоит недооценивать Spock и тесты на Groovy, они действительно получаются менее объемными по количеству кода и более читаемыми.

Источник