Интересный доклад. Есть только один вопрос. На 7:07 приводится пример unit-теста, который сложно написать для Spring. Из чего делается вывод, что, мол, так делать не надо. Но ведь это же не unit-тест. По факту мы тестируем не один класс, а сразу три: resolver, composer и properties. Если хотя бы один из них поменяется, могут по цепочке упасть и все тесты для resolver, чего происходить не должно. По-хорошему мы должны передавать mock от WordsComposer и задавать ему необходимое поведение. Таким образом можно и покрыть большинство тест-кейсов, и не сталкиваться с проблемой, что отсутствует user.properties.
Приложенеи с экспертами улыбнуло) А в остальном - повторение документации. Я так и не понял как ПРАВИЛЬНО тестировать в SpringBoot (интеграционные тесты): стратегия, куда ложить ИТ-тесты, куда ложить юнит-тесты, именование классов, как запустить только юнит-тесты, как запустить только интеграционные, какие компоненты тестировать в связке и сколько их должно быть чтобы спать спокойно. Неплохо было бы в продолжении осветить свой опыт, "как делать?" а не "как можно делать?".
Чтобы быть спокойным, надо тестировать как можно больше. Но это не бесплатно (увеличивается время на старт контекста). Компромисс вы сами должны найти. А по набору тестов вообще все просто. Либо сьюты делаете сердствами junit (Test Suite), либо аннотации проставляете и тестируете отдельные группы через surefire, либо тот же surefire, но по маске имен файлов (но тут вы сразу должны придерживаться правил именования).
Евгений опытный докладчик, время на докладе ограничено. Когда Евгений видел, что объяснения его коллеги неточные или не очень понятные - он перебивал и уточнял. Да, может не очень красиво, но без вставок Евгения доклад был бы менее понятным.
Школа магии и волшебствп Хогвартс: ищешь в фолиантах подходящее @заклинание, правильно произносишь, и ждёшь, чтобы все заработало и при этом не убило.
Ребята молодцы! Смотрю выступление третий раз, сейчас только до конца разобрался, что к чему, так как не хватало опыта
Интересный доклад. Есть только один вопрос. На 7:07 приводится пример unit-теста, который сложно написать для Spring. Из чего делается вывод, что, мол, так делать не надо. Но ведь это же не unit-тест. По факту мы тестируем не один класс, а сразу три: resolver, composer и properties. Если хотя бы один из них поменяется, могут по цепочке упасть и все тесты для resolver, чего происходить не должно. По-хорошему мы должны передавать mock от WordsComposer и задавать ему необходимое поведение. Таким образом можно и покрыть большинство тест-кейсов, и не сталкиваться с проблемой, что отсутствует user.properties.
доклад как всегда на высоте! спасибо!
спасибо, очень сложная тема, на 5 раз я наконец разобрался как это работает))
Очень полезно, спасибо. Вот это "сканирование вверх", а затем "сканирование вниз" для меня было не очевидно, отлично продемонстрировали это в докладе.
я решил свою проблему! как раз бины из "продакшна" мешались в контексте. Ну вот и пригодился мне этот доклад)
Как такую жесть вообще можно обьяснять и не запутаться..
Да тут можно смотреть и запутаться )
Приложенеи с экспертами улыбнуло) А в остальном - повторение документации. Я так и не понял как ПРАВИЛЬНО тестировать в SpringBoot (интеграционные тесты): стратегия, куда ложить ИТ-тесты, куда ложить юнит-тесты, именование классов, как запустить только юнит-тесты, как запустить только интеграционные, какие компоненты тестировать в связке и сколько их должно быть чтобы спать спокойно. Неплохо было бы в продолжении осветить свой опыт, "как делать?" а не "как можно делать?".
Так и не понял, как заставить людей не писать «ложить» :)
Чтобы быть спокойным, надо тестировать как можно больше. Но это не бесплатно (увеличивается время на старт контекста). Компромисс вы сами должны найти. А по набору тестов вообще все просто. Либо сьюты делаете сердствами junit (Test Suite), либо аннотации проставляете и тестируете отдельные группы через surefire, либо тот же surefire, но по маске имен файлов (но тут вы сразу должны придерживаться правил именования).
Супер!!!
Интересно, Евгений в такой же манере работает в команде с её членами в реальных проектах, как он работал с Кириллом на докладе?
Однако с таким Тим-лидом не пропадёшь и с юмором и не кричит ;)
EJB захлебывается от слюн глядя на спринг
штепсель и тарапунька
Где можно код посмотреть?
github.com/lavcraft/conference-test-with-spring-boot-test
Программирование превратилось в гадание.
Пили свой очереднярский велосипед и не гадай ;)
Если последние 5 минут посмотреть видео на 0.75 можно получить истинное удовольствие.
Получаем пьяного Женю
3:30😂😂😂
Звук моментами подшипивает
тараторят, перебиавают друг друга.. Борисов давит...
доклад не очень качественный
Евгений опытный докладчик, время на докладе ограничено. Когда Евгений видел, что объяснения его коллеги неточные или не очень понятные - он перебивал и уточнял. Да, может не очень красиво, но без вставок Евгения доклад был бы менее понятным.
это капец. 100500 способов выстрелить себе в ногу. Не зря я не люблю спринг
Видимо, совсем для русско-говорящих. Документация, куча комментариев в исходном коде... Но мы ж не читатели, мы писатели :-)
Как вы задолбали своими понтами... Учитесь у индусов.