RI
Size: a a a
2018 February 28
RI
я использую DI чтобы заинжектить config из которого возьму ключ (secret)
RI
А в тесте я могу передать какой-то конфиг и протестировать работу сервиса
RI
по факту secret прилетает из System.getenv("NAME_OF_ENV_VAR")
А
хм, прикольно)
RI
и я бы мог прямо в сервисе сделать вызов этого getenv
RI
но тогда бы не смог так протестировать код
RI
Вот на пальцах зачем DI, как можно тестировать и почему тесты улучшают качество кода
DT
иногда вместо написания тестов достаточно предположить, а как код можно протестировать. если код сложно тестировать, скорее всего, это такой себе код
I
и я бы мог прямо в сервисе сделать вызов этого getenv
А мог бы параметром передать “key” прям в функцию
и не потребовалось бы ни интерфейсов ни моков.
и не потребовалось бы ни интерфейсов ни моков.
RI
А мог бы параметром передать “key” прям в функцию
и не потребовалось бы ни интерфейсов ни моков.
и не потребовалось бы ни интерфейсов ни моков.
Ну тогда его вызывающий код должен был бы получить из конфига, и его в свою очередь стало бы сложнее тестировать 🤔 ну или колличество параметров выросло
BV
Я в часто пишу утилиты и делаю Ди для них просто руками просто передавая всё в конструктор, удобно очень
QH
Я в часто пишу утилиты и делаю Ди для них просто руками просто передавая всё в конструктор, удобно очень
есть примеры?
2018 March 01
BV
есть примеры?
Это всё в закрытых репах, но там нечего показывать. Просто в создаёшь или в методе или в классе все зависимости подряд и передашь в конструкторы то что создал до этого
DS
Тесты ещё можно рассматривать как открытую документацию. Хорошее сопровождение улучшает понимание проекта.
DS
Бывает что-то забудешь, посмотришь в тесты и всё сразу понятно
SS
Тесты - это спецификация вашей бизнес логики. Потому что даже если потеряется код с бизнес-логикой, но останутся тесты, которые ее покрывают, то по ним можно будет все восстановить.
