Нужен ли Mockito, если у вас Kotlin?

[Borz]

а можно просто использовать mockk:

val user = mockk<ApplicationUser>{
  every { displayName } returns "John Doe"
  every { emailAddress } returns "[e-mail]"
}

или вообще иерархию замокировать: https://mockk.io/#hierarchical-mocking

UPD: и обратите ещё внимание на kotest и faker

[dimskiy]

Автор предлагает не использовать моковый фреймворк, а вы предлагаете использовать другой моковый фреймворк, еще более многословный и поощряющий говнокод (тест статики, например)

[Borz]

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

статику тоже иногда надо замокировать - когда вы тестируете код выше её. Тот же "object" вполне себе статика на класс но при этом, вполне себе законная конструкция в Kotlin

ЗЫ: на примерах уровня HelloWorld любое использование фреймворков кажется избыточным

[dimskiy]

Я подчеркнул только бессмысленность вашего примера. Очевидно, что фреймворк доя тестов удобнее чем его отсутствие. Что касается статики - имхо, если для тестов вам приходится ее мокать, то почти наверняка вы сделали что-то не так

[Borz]

смысл в примере в том, что как аргументация для статьи была озвучена фраза `код стал более "тяжелым" для восприятия` при использовании сторонней библиотеки, которая изначально не была создана под Kotlin

[e_Hector]

Да, но в таком варианте растет количество "не естественного" синтаксиса, имею в виду конструкции библиотеки every, returns вместо "родных" языковых override

Плюс, сходу не понятно, как сделать собственное поведение для мокируемого метода?

Например, как будет выглядет вот такой мок, но сделанный на mockk

fun repository(repositoryId: Int, origin: Repository? = null, project: Project? = null) = object : Repository by proxy() {
    override fun getId() = repositoryId
    override fun getState() = AVAILABLE
    override fun getOrigin() = origin
    override fun isFork() = getOrigin() != null
    override fun getProject() = project!!
    override fun equals(other: Any?) = (other as? Repository)?.id == id
    override fun hashCode() = id.hashCode()
    override fun getName() = "Repository #$id"
    override fun getSlug() = "repository-$id"
    override fun toString() = name
}

p.s. Вариант moсkk выглядит лучше, чем mockito, но концептуальные претензии такие же

[Borz]

как в вашем подходе проверить, что метод, к примеру isFork, был вызван не более одного раза?

[loltrol]

Очевидно же что писать свой велосипед с еще более весёлыми конструкциями. С вероятностью 99% при переходе проекта с уровня hello world на уровень решения прикладных задач выйдет или каша, или решение ничем не "уступающее" в концептуальном плане mokk.

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

[e_Hector]

Никак :)

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

Я за то, чтобы не тащить к себе хоть и крутой, но избыточный инструмент.