Обращение к внешнему сервису я оборачиваю классом оберткой. Внутри либо try catch с возвратом null/default, либо проброс исключения наверх.
Смысла тестировать этот код юнит-тестами с моками я не вижу. Получится тестирование моков. Интеграционный с реальным вызовом по http у меня идет даже больше как песочница, где я могу быстро пощупать сервис.
А вот как бизнес-логика работает с хорошим/плохим ответом от внешнего сервиса — там да. Но там у меня тоже интеграционные + моки на вот эти классы-обертки.
Тоже пришел к примерно таким же выводам, как и в статье.
Юнит-тесты слишком мелкие и хрупкие, но они отлично подходят для тестирования каких-нибудь алгоритмов и расчетов. Т.е. там где чистый код на языке программирования, без вызовов внешних систем/БД и так далее. Для таких случаев я их и использую. Моки в 95% там и не нужны.
В основном я пишу интеграционные (функциональные).
На одном из проектов видел следующий подход — утилита, которая кидается http запросами к web api. Утилита самописная, тесты оформляются в виде внешних json файлов. Оставляя удобство за скобками — мне этот подход не очень понравился. Это было больше похоже на smoke тестирование, нежели проверку конкретных сложносоставных кейсов.
Я же выбрал несколько другой — интеграционные тесты на бизнес-логику и все что ниже (обращения к БД). БД я подготавливаю специальным образом. Раньше делал восстановление БД перед тестами, в последнее время перешел на запуск тестов в транзакциях с откатом. Активно использую атрибут TestCase из NUnit, чтобы натравить на один блок кода несколько различных кейсов. Вызовы внешних чужих сервисов (погода, гео-кодинг и тому подобные) обычно делаю через моки. При таком подходе не надо поднимать целый веб-сервис. Достаточно зарезолвить из контейнера экземпляр тестируемого бизнес-кода. Но минусы все равно есть — такие тесты менее хрупкие, но не защищены от изменений структуры моделей и dto. Зато отлично защищают при рефакторинге и доработках.
Для тестирования обращений к внешним вызовам — пишу отдельные интеграционные тесты. Там непосредственно вызывается некий сервис по http. Эти тесты в отдельной сборке и не включены CI/DC, чтобы не тратить бабло платных внешних сервисов при каждом прогоне.
И еще надо взять за основу правило: пришел баг в техподдержку — дописал тест.
То, что вы описали — это не юнит-тест. О чем в статье и говорится:
Любопытно, что некоторые разработчики в подобных ситуациях в конечном итоге всё-таки пишут интегральные тесты, но по-прежнему называют их юнит-тестами.
Единственное, что плохо делает монолит — это скейлится
Причем в данном случае масштабируется довольно хорошо — под каждую пиццерию выделенная виртуалка с копией монолита. Тем самым решается куча вопросов:
Отказоустойчивость — упавшая одна виртуалка никак не влияет на все остальные 599
Надежность — все обращения в рамках одного «физического» компьютера, нет обращений по сети. Опционально можно разве что разбить сервер-приложений и сервер-БД
Распределение нагрузки — думаю такой выделенный монолит легко выдержит нагрузку с одной пиццерии
Своего рода CDN — для Владивостока виртуалка поднимается в дата центре во Владивостоке
Тестировать обновления — можно только на одной машине, опять же все остальные спокойно работают
Можно вообще подумать в сторону копии в самой пиццерии с синхронизацией в облако — тогда отсутствие интернета не застопорит работу пиццерии. Но тут конечно больше вопросов, чем ответов
Можно даже распределить финансовые затраты — стоимость аренды сервера вешается на пиццерию
Проблем сходу видно три:
Пользователи — должны иметь сквозной идентификатор, потому что один и тот же человек может приехать в другой город и заказать пиццу там — вот для них надо выделить общую базу
Консолидированные отчеты по всем пиццериям — но тут достаточно сливать все данные из всех мастеров в одну отдельную БД с такой же структурой и поменять строку подключения в админке
Обновление всех этих монолитов, но с микросервисами такая же фигня
Если есть понимание, что проект дальше определенного состояния не пойдет и ему будет достаточно написать код в контроллерах или хранимках и без тестов — то никто не запрещает этого делать. Даже наоборот, не будет лишней сложности. Или, например, будут использованы внутренние инструменты СУБД, которые для данной задачи будут подходить лучше.
Но главная проблема в изменчивости требований. С опытом начинаешь понимать, что есть неиллюзорный шанс однажды все переписать. Очень не хочется этого делать. Ни мне, как программисту, ни бизнесу. Отсюда все эти — «На одну кнопку две недели? Как??!!!». И поэтому подкладываешь соломку заранее. Где-то по простому — сразу не пишешь код в контроллерах или хранимках, потому что это дешево. Где-то оставляешь задел на вероятное будущее, которое может и не наступить. А заранее это делать дорого, да и есть более важные задачи. Все эти решения принимаются на основе опыта, видимого потенциала конкретного проекта и деадлайнов.
Пожалуй единственная категория проектов, где было все (или почти все) заранее известно — это для гос. учреждений по водопаду. На моей практике — такие проекты никогда серьезно не развивались. Их либо выкидывали совсем, либо заменяли другими. Я там мог сложить бизнес логику в хранимки и 5-10 лет это никого бы не парило.
А когда дело касается государственной машины — там полный ахтунг. Когда на сайте суда написано, что можно подать иск в электронном виде. Ты его подаешь через ГАС Правосудие, а потом Почтой России приходит определение суда, что иск должен быть на бумажном носителе. Или когда обжалование штрафа висит в суде и ждешь заседания, а ФССП списывает этот штраф с твоего банковского счета.
Мне, как программисту, эти дикие и очевидные противоречия сильно бросаются в глаза, а толпа людей по ту сторону — даже не замечают.
Я не про конкретную группу программистов, а про то, что в целом люди инженерных специальностей обладают аналитическим складом ума, а бизнес-аналитики и программисты-аналитики в ИТ еще и натаскиваются на проверку различных тест-кейсов. И это помогает разбираться в законах/медицине порой лучше основной массы юристов и врачей.
Я много раз попадал на врачей-джуниоров и крайне редко на врачей-сениоров. Один раз даже был «доктор хаус». Так вот последние — как раз смотрят на пациента в целом, анализируют информацию всесторонне насколько это возможно, а не лечат по протоколам, даже пальпацию проводят по иному. Как раз все то, о чем написано в статье.
В статье говориться не то том, что они не работают, а о том, что их применяют бездумно или протоколы лечат следствие, а не причину. Даже проколы в онкологии — это лечение следствия (раковой опухоли), а не причины (судя по тем статьям, которые я читал — это сбой в механизме самовосстановления клеток и нежелательных мутаций клеток — условно все люди болеют раком, но организм сам с ним справляется каждый день, просто у некоторых этот механизм дает сбой).
По-моему одна из лучших статей про медицину. И лишний раз доказывает, что программисты с аналитическим складом ума и тестирующие все кейсы — смогут стать самыми лучшими экономистами, законотворцами, государственными управленцами и врачами.
Уточните, пожалуйста, как связаны эти два события?
Сначала надо было поработать в офисе в Новосибирске некоторое время, а потом релокация в США. Я не помню уже по какой визе, H1B или L1. Но и по H1B тоже были определенные сроки.
Вы невнимательно читали. Мне пообещали на собеседованиях $75k и $100к, но только после того, как меня переведут в американский офис. В тех вакансиях зарплата не была указана.
Когда там работает хотя бы один русский — все гораздо проще. Но и без везения не обошлось. Временная зона вообще не была проблемой. Я работал в свое локальное время. Своим вечером (у них утро) я был онлайн для обсуждений и вопросов, посещал митинги. А так же делал срочные задачи, если они были.
Это и повышенный стресс, и невозможность планировать все с хотя бы на неделю вперед, и отсутствие отпуска (если ты не сумел как-то спланировать и оплтатить его себе сам), и отсыхание социальных связей.
Я не столкнулся с этим. То, что вы описали больше подходит фрилансу. У меня же была удаленная работа — 8 (по желанию 10-12) часов в день. 5 дней в неделю. На протяжении всех этих 10 лет выходные, праздники, отпуска, отгулы и больничные были. Переработки оплачивались. Отпуска можно было запланировать. Все как на обычной работе, разве что не ездил каждый день в офис. Но я так и хотел.
Насчет социальных связей. Тут все еще более субъективно. Да, общения становится меньше, с этим не поспорить. Но я интроверт и в принципе к объему общения не требователен. Только в последний год-два стали посещать мысли — вот бы в офис, там весело. При этом я не перестал общаться с родителями, друзьями и семьей.
Смысла тестировать этот код юнит-тестами с моками я не вижу. Получится тестирование моков. Интеграционный с реальным вызовом по http у меня идет даже больше как песочница, где я могу быстро пощупать сервис.
А вот как бизнес-логика работает с хорошим/плохим ответом от внешнего сервиса — там да. Но там у меня тоже интеграционные + моки на вот эти классы-обертки.
Юнит-тесты слишком мелкие и хрупкие, но они отлично подходят для тестирования каких-нибудь алгоритмов и расчетов. Т.е. там где чистый код на языке программирования, без вызовов внешних систем/БД и так далее. Для таких случаев я их и использую. Моки в 95% там и не нужны.
В основном я пишу интеграционные (функциональные).
На одном из проектов видел следующий подход — утилита, которая кидается http запросами к web api. Утилита самописная, тесты оформляются в виде внешних json файлов. Оставляя удобство за скобками — мне этот подход не очень понравился. Это было больше похоже на smoke тестирование, нежели проверку конкретных сложносоставных кейсов.
Я же выбрал несколько другой — интеграционные тесты на бизнес-логику и все что ниже (обращения к БД). БД я подготавливаю специальным образом. Раньше делал восстановление БД перед тестами, в последнее время перешел на запуск тестов в транзакциях с откатом. Активно использую атрибут TestCase из NUnit, чтобы натравить на один блок кода несколько различных кейсов. Вызовы внешних чужих сервисов (погода, гео-кодинг и тому подобные) обычно делаю через моки. При таком подходе не надо поднимать целый веб-сервис. Достаточно зарезолвить из контейнера экземпляр тестируемого бизнес-кода. Но минусы все равно есть — такие тесты менее хрупкие, но не защищены от изменений структуры моделей и dto. Зато отлично защищают при рефакторинге и доработках.
Для тестирования обращений к внешним вызовам — пишу отдельные интеграционные тесты. Там непосредственно вызывается некий сервис по http. Эти тесты в отдельной сборке и не включены CI/DC, чтобы не тратить бабло платных внешних сервисов при каждом прогоне.
И еще надо взять за основу правило: пришел баг в техподдержку — дописал тест.
Причем в данном случае масштабируется довольно хорошо — под каждую пиццерию выделенная виртуалка с копией монолита. Тем самым решается куча вопросов:
Проблем сходу видно три:
Но главная проблема в изменчивости требований. С опытом начинаешь понимать, что есть неиллюзорный шанс однажды все переписать. Очень не хочется этого делать. Ни мне, как программисту, ни бизнесу. Отсюда все эти — «На одну кнопку две недели? Как??!!!». И поэтому подкладываешь соломку заранее. Где-то по простому — сразу не пишешь код в контроллерах или хранимках, потому что это дешево. Где-то оставляешь задел на вероятное будущее, которое может и не наступить. А заранее это делать дорого, да и есть более важные задачи. Все эти решения принимаются на основе опыта, видимого потенциала конкретного проекта и деадлайнов.
Пожалуй единственная категория проектов, где было все (или почти все) заранее известно — это для гос. учреждений по водопаду. На моей практике — такие проекты никогда серьезно не развивались. Их либо выкидывали совсем, либо заменяли другими. Я там мог сложить бизнес логику в хранимки и 5-10 лет это никого бы не парило.
Мне, как программисту, эти дикие и очевидные противоречия сильно бросаются в глаза, а толпа людей по ту сторону — даже не замечают.
Я много раз попадал на врачей-джуниоров и крайне редко на врачей-сениоров. Один раз даже был «доктор хаус». Так вот последние — как раз смотрят на пациента в целом, анализируют информацию всесторонне насколько это возможно, а не лечат по протоколам, даже пальпацию проводят по иному. Как раз все то, о чем написано в статье.
В статье говориться не то том, что они не работают, а о том, что их применяют бездумно или протоколы лечат следствие, а не причину. Даже проколы в онкологии — это лечение следствия (раковой опухоли), а не причины (судя по тем статьям, которые я читал — это сбой в механизме самовосстановления клеток и нежелательных мутаций клеток — условно все люди болеют раком, но организм сам с ним справляется каждый день, просто у некоторых этот механизм дает сбой).
По-моему одна из лучших статей про медицину. И лишний раз доказывает, что программисты с аналитическим складом ума и тестирующие все кейсы — смогут стать самыми лучшими экономистами, законотворцами, государственными управленцами и врачами.
Каждому свое. Мне программирование приносит внутреннюю гармонию, но я не хочу платить ипотеку 20 лет. Приятное с полезным так сказать.
Сначала надо было поработать в офисе в Новосибирске некоторое время, а потом релокация в США. Я не помню уже по какой визе, H1B или L1. Но и по H1B тоже были определенные сроки.
Я не столкнулся с этим. То, что вы описали больше подходит фрилансу. У меня же была удаленная работа — 8 (по желанию 10-12) часов в день. 5 дней в неделю. На протяжении всех этих 10 лет выходные, праздники, отпуска, отгулы и больничные были. Переработки оплачивались. Отпуска можно было запланировать. Все как на обычной работе, разве что не ездил каждый день в офис. Но я так и хотел.
Насчет социальных связей. Тут все еще более субъективно. Да, общения становится меньше, с этим не поспорить. Но я интроверт и в принципе к объему общения не требователен. Только в последний год-два стали посещать мысли — вот бы в офис, там весело. При этом я не перестал общаться с родителями, друзьями и семьей.