TsyklopАндрей Панфилов, Ответ на вопросы выше - никак? я так понимаю.
Ответ - моканьем всего что вне сервиса

Андрей ПанфиловmaytonМоки - это правильный ответ. Но писать хорошие тесты - большое искусство.Моки к хорошим тестам никакого отношения не имеют, потому что все моки выглядят примерно так: Покритикуйте/оцените spring-boot приложение - это зло которое лучше избегать при любом удобном случае.
где вы там нормальные моки с нормальными тестами увидали?

одна из целей тестов - фиксировать текущий функционал. если они эту задачу выполняют - значит это хорошие тесты.
если они падают после того как вы поменяли схему базы - значит это хорошие тесты. если вы пошатали кусок кода и тесты упали - значит это снова хорошие тесты.
и да - тесты надо поддерживать. равно так же как и писать.

cossack5У нас юнит-тесты как интеграционные: разворачивается база, накатываются все скрипты, потом прогоняются тесты. Занимает все это дело немало времени.
так если ваши тесты юзают базу - значит они интеграционные )) и да.. собссно везде так. а где так нет - там проект пишут весьма самонадеянные люди. я больше скажу, тупо код писать и рефачить обложенный тестами в разы быстрее и проще. особенно рефачить.

просто, порой бывают весьма запутанные флоу или тупо приложение стартует несколько минут, и требует еще мешок сервисов сверху, то без тестов писать код становится тупо нереально.

и да, имхо, если юнит тест вылезает с проверкой функционала за пределы класса (ну, или ладно, за пределы инъекций) - это уже интеграционный тест.

maytonЯ против замены оригинальной dbms. Это не совсем честное тестирование. Особенно если мы отошли далеко от ansi sql (это часто бывает в ent) и используем plsql/pgsql и прочие процедурные языки.
полностью согласен. если юнит то мокай вызовы в репу. если интеграционный то юзай ту же самую базу с пустой схемой но такой же. можно не коммитить

Андрей ПанфиловandreykaTгде вы там нормальные моки с нормальными тестами увидали?Нигде, это просто гипертрофированный пример концепции увеличения покрытия кода тестами, что, собственно, моки из себя и представляют: покрытие увеличивается, а толку нет никакого.

andreykaTодна из целей тестов - фиксировать текущий функционал. если они эту задачу выполняют - значит это хорошие тесты.
если они падают после того как вы поменяли схему базы - значит это хорошие тесты. если вы пошатали кусок кода и тесты упали - значит это снова хорошие тесты.
и да - тесты надо поддерживать. равно так же как и писать.Все правда ровно до тех пор, пока это не касается моканья БД - любая встраиваемая БД (типа sqllite или hsqldb) даст 100 очков форы мокам.
а потом ты заюзаешь какой нибудь хитрый функционал по незнанию своего скулайта, твои тесты начнут проходить, зато тоже самое на реале будет падать

про тесты того парня ну они вроде как минимум тестируют контроллер замоканный. никто ж не говорит что этих тестов достаточно. просто такие тесты в идеале должны быть написаны на все публичные методы всех классов. хотя бы такие.
и еще интеграционных чуток.

где то видал пирамиду тестирования, диаграмму.

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

я с ней почти согласен.

впрочем, в классических спринговых вебсервисах основная логика зашита в сервисном слое и я считаю что там ндо примерно равное количество юнитов и интеграционных.

имхо, если достоверно можешь протестировать юнитом -пиши юниты. если не можешь - добавляй интеграционные.

ты просто топишь за интеграционные тесты я с тобой согласен. не вижу смысла писать юнит если в методе логики ноль и только перекладывание из поля в поле.

еще раз.. юнит тесты как и интеграционные - обязаны фиксировать текущий (ожидаемый) функционал. если они валятся при рефаке ну так окей. это хорошие тесты. поддержка тестов - это отдельная дисциплина.

у тебя никогда не бывало что ты поменял какой то флоу и у тебя попадо половина тестов покрывающих код который ты пошатал? при этом код работает правильно.

это называется девелопмент. поздравляю можешь еще все тесты закомментить и сказать заказчику и так сойдет - работает же

кстати, насчет структур данных. допустим у тебя есть структура где каждый узел знает только о своих детях но не знает о своих родителях - как ты на родителя переместишься? а? вариант 1) построишь вспомогательную структуру где будешь хранить инфу и о предках (ну или поверх существующей - не важно) вариант 2) пойдешь от рута вниз в поисках детей. оба варианта так себе и имеют как плюсы так и минусы.