Евгений, дай Бог Вам здоровья, сил и вдохновения на продолжение различных направлений Вашей деятельности на канале (обучающие видео, менторинг, мок-интервью). Качество и подача материала на высоте. Ждем следующих видео на Вашем канале! Удачи!
Обалдеть! Вот это курс! Евгений, ты реально меценат. Меценат с большой буквы! Огромная благодарность за то делишься экспертизой. Таких людей должно быть больше! Жень, от всей души желаю тебе всего самого доброго. Тебе и твоим близким благополучия! Еще раз спасибо за потрясающий материал.
3:40:52 не понял, зачем в entity сетится email? Ведь мы проверяем изменение email, поэтому в сущности должен быть старый email, а в dto - новый. Или я чего-то не понимаю?
Евгений, приветствую! При тестировании сервисного слоя ( 1:15:00 и далее ) мы присваиваем методам мока репозитория findByEmail и getById поведение, которым они не обладают и обладать, в моём понимании, не должны - пробрасывание исключений. Не было бы правильнее делать .willReturn(null) ? И уже этот null обрабатывать в методе сервиса и дожидаться проброса исключения там? Просто в моём понимании мы не тестируем функциональность по пробросу исключений в методе сервиса при получении null от репозитория. Надеюсь понятно написал) Для наглядности укажу код : Метод из ролика : -- public void givenIncorrectEmail_whenGetDeveloperByEmail_thanExceptionIsThrown() { //given BDDMockito.given(repository.findByEmail(anyString())) .willThrow(DeveloperIsNotExistException.class); //when assertThrows(DeveloperIsNotExistException.class, ()-> serviceUnderTest.getDeveloperByEmail(DataUtils.getJohnScottTransient().getEmail())); //then } Мой метод : -- public void givenIncorrectEmail_whenGetDeveloperByEmail_thanExceptionIsThrown() { //given BDDMockito.given( repository.findByEmail(anyString())) .willReturn(null); //when assertThrows(DeveloperIsNotExistException.class, ()-> serviceUnderTest.getDeveloperByEmail(DataUtils.getJohnScottTransient().getEmail())); //then }
@@EugeneSuleimanov если в самом спринге везде возвращается optional, то я предполагаю, что это основной кейс. Но бывают случаи, когда удобнее получать реальную сущность. Поэтому такая возможность оставлена для кастомных методов. Но это не основной кейс, как я думаю) Могу ошибаться) Другими словами, какой вариант предпочтительнее в таких задачах, типа рассмотренной в видео?
Спасибо за видео, Евгений! Сталкивались с Citrus Framework? Последнее время всё чаще появляется в инфополе и даже доводилось его попробовать. Было бы интересно посмотреть по нему видео от Вас :) Будет хорошим дополнением к этому видео. Что думаете?
Крутое видео. Просто ТОП, Жень! Как относишься к мнению, что мокать есть смысл только внешние сервисы, которые доступны третьим лицам, в ином случае такие сервисы можно считать внутренними (относительно клиентов и любых третьих лиц)? Например БД, доступную только из нашего сервиса, нет смысла мокать, т.к. для любого внешнего сервиса она является частью нашей внутренней реализации.
Привет Евгений. Спасибо за видео. Хотел бы спросить, работали ли Вы с C#/.Net стеком? Если да, то насколько много преимуществ он имеет по сравнению с Java платформой?
Евгений, а есть смысл изучать реактивность после выхода 21й джавы с её виртуальными потоками? Вообще, есть ли нормальное сравнение быстродействия этих двух технологий в проме?
@@EugeneSuleimanov да, я работал немного с реактивностью в спринговом гейтвее, но уже года 2 назад говорили, что не стоит в неё закапываться, ведь скоро выйдут виртуальные потоки. Сейчас частый случай, что переходят на 21ю джаву, вот я так и не понимаю - будут ли писать новые реактивные проекты, или максимум поддерживать имеющиеся
спасибо! подскажите, а действительно нужно тестировать базовые методы типа save, findAll или saveAll? это было показано для примера, разве в реальном коде не тестируют только какую то кастомную логику, кастомные запросы?
@@EugeneSuleimanov спасибо за ответ! подскажите еще пжлст, а можно проверять конкретно sql запросы при тестировании repository? например, проверить отсутствие проблемы N+1, или хибернейт может разные алиасы каждый раз делать и такое невозможно протестить?
Изучаю сейчас Junit и столкнулся с проблемой: как тестировать контроллеры , которые защищены с помощью Spring security ? Если кто-то может помочь, буду очень признателен
Евгений талант, который не жалеет своего времени делиться знаниями и опытом, спасибо большое! Жаль что по C# на просторах ютуба нет такого же Евгения(
Большое спасибо за поддержку!
Это самый лучший канал по Java)
Спасибо за поддержку :)
Низкий поклон к твоему труду, спасибо большое, за то, что ты делаешь!
Спасибо за поддержку!
Евгений, дай Бог Вам здоровья, сил и вдохновения на продолжение различных направлений Вашей деятельности на канале (обучающие видео, менторинг, мок-интервью). Качество и подача материала на высоте.
Ждем следующих видео на Вашем канале!
Удачи!
Большое спасибо за поддержку!
Лучший канал по Java! Огромное спасибо, Евгений!!!
Спасибо за поддержку!
Обалдеть! Вот это курс! Евгений, ты реально меценат. Меценат с большой буквы!
Огромная благодарность за то делишься экспертизой. Таких людей должно быть больше!
Жень, от всей души желаю тебе всего самого доброго. Тебе и твоим близким благополучия!
Еще раз спасибо за потрясающий материал.
Большое спасибо за поддержку!
В одном видео все, что я не мог найти в разных источниках. 👍И отличная подача.
Большое спасибо за отзыв!
3:40:52 не понял, зачем в entity сетится email?
Ведь мы проверяем изменение email, поэтому в сущности должен быть старый email, а в dto - новый.
Или я чего-то не понимаю?
Спасибо, Женя! по качеству этот материал намного превосходит все подобные платные курсы. я бы не пожалел даже купить такое.
Большое спасибо за поддержку!
Великолепная, монструозная, важнейшая работа! Спасибо, мастер)
Большое спасибо за поддержку!
Это просто бомба, спасибо за знания!
Спасибо за отзыв!
Евгений, приветствую! При тестировании сервисного слоя ( 1:15:00 и далее ) мы присваиваем методам мока репозитория findByEmail и getById поведение, которым они не обладают и обладать, в моём понимании, не должны - пробрасывание исключений. Не было бы правильнее делать .willReturn(null) ? И уже этот null обрабатывать в методе сервиса и дожидаться проброса исключения там? Просто в моём понимании мы не тестируем функциональность по пробросу исключений в методе сервиса при получении null от репозитория. Надеюсь понятно написал) Для наглядности укажу код :
Метод из ролика :
--
public void givenIncorrectEmail_whenGetDeveloperByEmail_thanExceptionIsThrown() {
//given
BDDMockito.given(repository.findByEmail(anyString()))
.willThrow(DeveloperIsNotExistException.class);
//when
assertThrows(DeveloperIsNotExistException.class, ()->
serviceUnderTest.getDeveloperByEmail(DataUtils.getJohnScottTransient().getEmail()));
//then
}
Мой метод :
--
public void givenIncorrectEmail_whenGetDeveloperByEmail_thanExceptionIsThrown() {
//given
BDDMockito.given( repository.findByEmail(anyString())) .willReturn(null);
//when
assertThrows(DeveloperIsNotExistException.class, ()->
serviceUnderTest.getDeveloperByEmail(DataUtils.getJohnScottTransient().getEmail()));
//then
}
Спасибо вам большие гайд! Долг искал норм гайд где бы понять методологию!
Спасибо за отзыв!
Очень полезное видео и сколько труда вложено, благодарю!
Большое спасибо за отзыв!
Очень круто - все по тестированию в одном видео! Евгений, спасибо за контент!
Спасибо за отзыв!
любимый Java разработчик) блогодарья вашему каналу я стану senior)
Спасибо за поддержку и успехов вам!
Спасибо Тебе добрый человек делишься своими трудами!
Спасибо за отзыв!
Как всегда. Подача материала супер. Спасибо за труд
Спасибо за поддержку!
Спасибо, Женя!) Давно уже нужно было это сделать))) Очень полезно)
Спасибо за поддержку, Юра!
спасибо Евгений за ваш труд
очень полезно
Спасибо за отзыв!
Спасибо Евгений, как всегда отличный материал🔥🔥🔥
Спасибо за поддержку!
Евгений, спасибо за отличное видео!)
Спасибо за отзыв!
Классный обзор про юнит тесты!!
Спасибо за отзыв!
Женя, огромное спасибо!
как раз будет чем вечером заняться :)
Большое спасибо за поддержку!
Спасибо за видео! В самом начале на 16:37 минуте билд должен запускаться с запущенным докером иначе падает при попытке билда
Спасибо огромное за ваш труд! Прекрасное видео!
Спасибо за отзыв!
Крайне годно, Женя ты лучший !!! :)
Спасибо за отзыв :)
то что нужно 👍
Огромное спасибо!
Спасибо за отзыв!
Благодарю за ваш труд!
Спасибо за поддержку!
Отличный курс, спасибо!
Вопрос: почему кастомные метода репозитория возвращают сущность, а не Optional?
Спасибо за отзыв!
Фреймворк позволяет возвращать как объект, так и optional.
@@EugeneSuleimanov так по best practices вроде лучше возвращать Optional?
Методы спринговых интерфейсов возвращают или List или Optional)
@@tiy2000 не встречал такого утверждения, если можете скинуть ссылки, буду признателен.
@@EugeneSuleimanov это было не утверждение, а вопрос)
@@EugeneSuleimanov если в самом спринге везде возвращается optional, то я предполагаю, что это основной кейс. Но бывают случаи, когда удобнее получать реальную сущность. Поэтому такая возможность оставлена для кастомных методов. Но это не основной кейс, как я думаю) Могу ошибаться)
Другими словами, какой вариант предпочтительнее в таких задачах, типа рассмотренной в видео?
Почти 4 часа - страшно ) Но посмотрю обязательно
Спасибо за комментарий!
Спасибо! Все круто и понятно!)
@@Dominic_Herzog спасибо за отзыв!
Супер, те що треба!!! Дякую!
Спасибо за отзыв!
@EugeneSuleimanov 2:51:21 а почему зависимость io.r2dbc:r2dbc-postgresql а не org.postgresql:r2dbc-postgresql ?
Спасибо за вопрос. Чаще работаю с ней, поэтому взял эту зависимость.
Женя! Ты топ! Спасибо!
Спасибо за поддержку!
ООО шик, я как раз тестировщик 😂
Спасибо за комментарий!
Шеф! Это золото а не курс!
Спасибо за отзыв :)
Почти 4 часа, огонь
Спасибо за отзыв!
Интересно и познавательно =)
Спасибо за поддержку!
Спасибо за видео, Евгений! Сталкивались с Citrus Framework? Последнее время всё чаще появляется в инфополе и даже доводилось его попробовать. Было бы интересно посмотреть по нему видео от Вас :) Будет хорошим дополнением к этому видео. Что думаете?
Лайк, подписка!
Спасибо за поддержку!
Огромное спасибо
@@savaxxxz спасибо за отзыв!
Крутое видео. Просто ТОП, Жень! Как относишься к мнению, что мокать есть смысл только внешние сервисы, которые доступны третьим лицам, в ином случае такие сервисы можно считать внутренними (относительно клиентов и любых третьих лиц)? Например БД, доступную только из нашего сервиса, нет смысла мокать, т.к. для любого внешнего сервиса она является частью нашей внутренней реализации.
Спасибо за поддержку!
В целом, согласен, что мокать нужно только то, что крайне и крайне сложность поддерживать или поднимать внутри периметра.
Привет Евгений. Спасибо за видео. Хотел бы спросить, работали ли Вы с C#/.Net стеком? Если да, то насколько много преимуществ он имеет по сравнению с Java платформой?
Спасибо за комментарий!
К сожалению, нет такого опыта и не смогу подсказать по преимуществам и недостаткам.
разработчики курсов по тестированию долго скрывали эту информацию!!!
чтобы написать тесты, нужно всего лишь...
Евгений, а есть смысл изучать реактивность после выхода 21й джавы с её виртуальными потоками?
Вообще, есть ли нормальное сравнение быстродействия этих двух технологий в проме?
Спасибо за комментарий!
Это несколько разные подходы и я бы рекомендовал ознакомиться с ними отдельно.
@@EugeneSuleimanov да, я работал немного с реактивностью в спринговом гейтвее, но уже года 2 назад говорили, что не стоит в неё закапываться, ведь скоро выйдут виртуальные потоки. Сейчас частый случай, что переходят на 21ю джаву, вот я так и не понимаю - будут ли писать новые реактивные проекты, или максимум поддерживать имеющиеся
А вот я так понял делейт сделен не идемпотентным для примера просто? Показать работу эксепшнов, да?
Спасибо за вопрос!
Да, все верно, акцент на тестировании.
@@EugeneSuleimanov спасибо
👍👍
Спасибо за комментарий!
спасибо! подскажите, а действительно нужно тестировать базовые методы типа save, findAll или saveAll? это было показано для примера, разве в реальном коде не тестируют только какую то кастомную логику, кастомные запросы?
@@Daniel-mo1iy спасибо за комментарий!
Обычно, не тестируются, здесь показаны просто примеры работы с тестами.
@@EugeneSuleimanov спасибо за ответ! подскажите еще пжлст, а можно проверять конкретно sql запросы при тестировании repository? например, проверить отсутствие проблемы N+1, или хибернейт может разные алиасы каждый раз делать и такое невозможно протестить?
Изучаю сейчас Junit и столкнулся с проблемой: как тестировать контроллеры , которые защищены с помощью Spring security ? Если кто-то может помочь, буду очень признателен
Большое спасибо! Но у меня при update срабатывает как insert новая запись. Не подскажите почему так?
@@ShintilesBayzakov спасибо аза отзыв!
Имеет смысл проверит реализацию метода isNew в классе сущности. Обычно, причина именно в этом.
@@EugeneSuleimanov спасибо) но я не понял) можно пример, если не трудно, прошу прощения!
+
Спасибо за комментарий!
Это самый лучший канал по Java)
Спасибо за поддержку :)