Интересный доклад. Есть только один вопрос. На 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 захлебывается от слюн глядя на спринг
3:30😂😂😂
Где можно код посмотреть?
github.com/lavcraft/conference-test-with-spring-boot-test
Звук моментами подшипивает
Программирование превратилось в гадание.
Пили свой очереднярский велосипед и не гадай ;)
Если последние 5 минут посмотреть видео на 0.75 можно получить истинное удовольствие.
Получаем пьяного Женю
тараторят, перебиавают друг друга.. Борисов давит...
доклад не очень качественный
Евгений опытный докладчик, время на докладе ограничено. Когда Евгений видел, что объяснения его коллеги неточные или не очень понятные - он перебивал и уточнял. Да, может не очень красиво, но без вставок Евгения доклад был бы менее понятным.
это капец. 100500 способов выстрелить себе в ногу. Не зря я не люблю спринг
Видимо, совсем для русско-говорящих. Документация, куча комментариев в исходном коде... Но мы ж не читатели, мы писатели :-)
Как вы задолбали своими понтами... Учитесь у индусов.