Телеграмм чат группы scala

Size: a a a

Scala User Group

2021 October 01

https://scalamock.org/
Каких-то особых подводных не заметил.
Также можно использовать любые джавовые инструменты, по вкусу.

источник

13:32пожаловаться #1

Oℕ

Oleg ℕizhnik in Scala User Group

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

источник

13:32пожаловаться #2

Artem Sokolov in Scala User Group

Поч нет. Вопрос же в выборе гранулрности. Для относительно низкоуровневых тестов те или иные стабы нужны. Ид и вы про какой-то конкретный кейс?

источник

13:33пожаловаться #3

Alexandr Fedorov in Scala User Group

Ну говорят там беда с кейс классами
Они почему-то не мокаются, надо детальнее смотреть

источник

13:33пожаловаться #4

Oℕ

Oleg ℕizhnik in Scala User Group

а вот зачем кейсклассы мокать это для меня совсем загадка

источник

13:33пожаловаться #5

Rajven in Scala User Group

Вот что-что, а кейс классы мокать не приходилось.

источник

13:33пожаловаться #6

Artem Sokolov in Scala User Group

Второй тезис можешь пожалуйста примером дополнить. Не оч понятно про что речь

источник

13:34пожаловаться #7

АМ

Азамат Макарчук... in Scala User Group

ну ты же не спросил "зачем", ты спросил "что"

источник

13:35пожаловаться #8

Alexandr Fedorov in Scala User Group

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

источник

13:35пожаловаться #9

Oℕ

Oleg ℕizhnik in Scala User Group

ну если у тебя есть какой-то там EnterprisePaymentModule и ты хочешь замокать у него приватный метод calculatePrice(lol, kek), так делать нельзя, потому что ты полагаешься, что у EnterprisePaymentModule есть в принципе такой метод, и это деталь реализации

вместо этого нужно вынести какой-то модуль
EnterpisePriceCalculator , подтянуть ссылку на него в EnterprisePaymentModule и мокать уже этот новый модуль

источник

13:36пожаловаться #10

Rajven in Scala User Group

Корректность всех публичных методов использующих его = его корректность, нет? Вообще, имхо, странно писать тесты на детали реализации, которые могут (и, скорее всего, будут) меняться.

источник

13:37пожаловаться #11

Oℕ

Oleg ℕizhnik in Scala User Group

этот клинкодороллер не мой, я просто твиты собираю

источник

13:37пожаловаться #12

Alexandr Fedorov in Scala User Group

Ну почему нет?
С таким подходом вообще можно тесты не писать
А тест кавередж 80% оставить парням из Booking например

источник

13:38пожаловаться #13

Vladislav Kovalenko🐝... in Scala User Group

Почему им?

источник

13:39пожаловаться #14

Alexandr Fedorov in Scala User Group

Ну это про крутой Ci/Cd когда комит сразу в прод летит

источник

13:40пожаловаться #15

Aλexander Semenov in Scala User Group

Покрывать лучше acceptance тестами, которые вызывают реальные эндпоинты, а не моки и вот это всё.

источник

13:40пожаловаться #16

Rajven in Scala User Group

У нас юнит тестамы покрывают только публичные методы прописанные в интерфейсах.🤷
Да и тест кавередж достаточно холиварный показатель.

источник

13:41пожаловаться #17

Alexandr Fedorov in Scala User Group

Ладно, я понял.
Спасибо
Буду разбираться по проектной необходимости)

источник

13:41пожаловаться #18

Vladislav Kovalenko🐝... in Scala User Group

да нормальная моки и мокито тема, у нас тест коверейдж 90+%, все приватные методы протестированы, кейсклассы замоканы, тесты по двести строк на кейс с when verify в столбик и продукт летает

источник

13:42пожаловаться #19

Artem Sokolov in Scala User Group

Это же шутка да

источник

13:43пожаловаться #20