PE
Ааа, то есть kotlin мне не видать с junit.. жааль
почему
отлично там все, просто нет всяких дсл хайпа в либе джунита
да и не нужно, там и так лаконично все)
Size: a a a
2021 March 31
KX
Всем Привет ребята! Как перенести две значение в одну переменную через for loop , чтобы в консоли вышло вот так " USA=+1", "RU=+7".
For((country,code...in array.indices)) это если ты те два массива в хешмэп затолкаешь.
TT
ну чисто для сравнения можно любые assert библиотеки попробовать, мы пользуемся Truth от Google, очень неплохая, жаль конечно что нет хорошей Kotlin обертки, но мы ей пользуемся целиком вместо Junit
Ну пишете про обёртку.. понял к чему это. А использовать с junit генератор свойств от kotest никак?
TT
Ну и их библиотеку ассертов
AM
Не, я говорю про Truth это библиотека для assert вот и все, что она для Java поэтому не всегда идеально работает в некоторых случаев (например с nullability)
Для нее ничего не нужно, это же просто assert, т.е. функцию проверяющая условия и выдающая красивую читабельную ошибку
Для нее ничего не нужно, это же просто assert, т.е. функцию проверяющая условия и выдающая красивую читабельную ошибку
AM
Понял, спасибо, осталось убедить лида и коллег не заниматься kotest . Они как не странно тоже не писали никогда тесты и повелись видимо на хайп )
Я тут посмотрел, как я вижу Kotest построен на раннере для Junit 5 так что он не будет работать из коробки для Android Instrumentation тестов, поддерживается только Junit 4 раннер официально: https://issuetracker.google.com/issues/127100532
AL
Да никакой лаконичности нет на самом деле, все те же функции, описывать "спек", задумка уровня "для того чтобы использовать dsl"
читается хуже чем нормальные тесты jUnit, по-мимо того, без плагина эти тесты хер запустишь, раннеры его не видят, коверадж с котестом работал у меня херово и не отображал правильный процент, ну лаконичности никакой нет, за исключением методов для ассерта, но это такая туфта, на фоне его дерьма
в замен предлагаю использовать JUnit 5/4!, если не нужно то что предлагает 5, то используй 4
читается хуже чем нормальные тесты jUnit, по-мимо того, без плагина эти тесты хер запустишь, раннеры его не видят, коверадж с котестом работал у меня херово и не отображал правильный процент, ну лаконичности никакой нет, за исключением методов для ассерта, но это такая туфта, на фоне его дерьма
в замен предлагаю использовать JUnit 5/4!, если не нужно то что предлагает 5, то используй 4
Я не знаю, может конечно именно на Андроиде с ним тяжело, но на проекте по Test Automation с ним проблем не возникло. Т.е. про необходимость плагина для идеи согласен, но дальше уже слишком субъективно, чтобы настолько говном поливать.
TT
Я не знаю, может конечно именно на Андроиде с ним тяжело, но на проекте по Test Automation с ним проблем не возникло. Т.е. про необходимость плагина для идеи согласен, но дальше уже слишком субъективно, чтобы настолько говном поливать.
Вот у меня и не получается Лида убедить что kotest гавно
AL
Я не знаю, может конечно именно на Андроиде с ним тяжело, но на проекте по Test Automation с ним проблем не возникло. Т.е. про необходимость плагина для идеи согласен, но дальше уже слишком субъективно, чтобы настолько говном поливать.
Т.е. это безусловно не какой-то game changer и обязательно нужно брать, но... не знаю, работает окей, ребята на проекте не жаловались (я предложил попробовать раз проект не такой большой, если что сам бы помог в более стандартный фреймворк конвертнуть)
TT
Ну нам конечно на андроид и надо
TT
Ну вот аргумент Лида что не хочет декларативное описание
TT
Не хочет кучу классов и длинные описания
TT
Я не писал ни на чём, мне сложно представить разницу
TT
Ну вот завести интеграционные с андроид тест не удалось
AL
Вот у меня и не получается Лида убедить что kotest гавно
Ну, может потому, что он не говно? :)
Опять-таки, не что-то, что НУЖНО тащить в проекте, местами проще и правильнее жить с более родными фреймворками для всего, а не накидывать больше плагинов. Но тем не менее, для нас оказалось удобной опцией в одном из проектов.
Опять-таки, не что-то, что НУЖНО тащить в проекте, местами проще и правильнее жить с более родными фреймворками для всего, а не накидывать больше плагинов. Но тем не менее, для нас оказалось удобной опцией в одном из проектов.
TT
Да и чем существенным отличтся раннеры 4 и 5 ?
TT
Ну, может потому, что он не говно? :)
Опять-таки, не что-то, что НУЖНО тащить в проекте, местами проще и правильнее жить с более родными фреймворками для всего, а не накидывать больше плагинов. Но тем не менее, для нас оказалось удобной опцией в одном из проектов.
Опять-таки, не что-то, что НУЖНО тащить в проекте, местами проще и правильнее жить с более родными фреймворками для всего, а не накидывать больше плагинов. Но тем не менее, для нас оказалось удобной опцией в одном из проектов.
Можно ведь использовать и то и другое? Для интеграционных junit , а так юнит котест
AL
Да и чем существенным отличтся раннеры 4 и 5 ?
Если смотреть через призму котеста - возможно ничем, просто зависимость разная.
https://github.com/kotest/kotest/tree/master/kotest-runner/kotest-runner-junit4
А так там довольно сильно менялся фреймворк. В базовых вещах всё конечно +- похоже, но вот механизмы для расширения тестов начинают сильно отличаться.
https://github.com/kotest/kotest/tree/master/kotest-runner/kotest-runner-junit4
А так там довольно сильно менялся фреймворк. В базовых вещах всё конечно +- похоже, но вот механизмы для расширения тестов начинают сильно отличаться.
AL
Можно ведь использовать и то и другое? Для интеграционных junit , а так юнит котест
А это уже просто избыточно будет, скакать между разными по стилю тестами только от того, что протестировать хочется больше, чем один класс/функцию - это перебор.