Организованное программирование | Кирилл Мокевнин

А всё таки, когда моки зло, а когда нет? Чтобы ответить на этот вопрос, сначала нужно разобраться с терминологией и сутью процесса. Сейчас моками называют вообще все что связано с подменой реализации в тестах. Но подмена это просто техника, она может использоваться для совсем разных задач. Представьте себе две ситуации. В одной мы подменяяем логер, который работает по http, чтобы он просто складывал данные в файл и не делал http запросов во время тестирования. В другой, в другой, мы проверяем что какой-то метод был вызван с определенными аргументами. И там и там работает подмена, но между этими ситуациями почти ничего общего с точки зрения решаемой задачи...

Начинаем серию прожарки фреймворков для тех кому интересно, что происходит в других стеках. Сегодня говорим про spring boot https://youtu.be/ElzbKGKjDrU?si=4rjFUinqkQFUQUJ4 (прошу прощения за звук, у меня был включен не тот микрофон)

Это из соседнего чата американских русскоязычных программистов

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

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