Восстановление состояния в тестах

И так, вы решили написать тесты на свой проект. Вопрос, как добиться изоляции тестов друг от друга, когда речь идет про интеграционные и функциональные тесты?

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

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

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

Ну и наконец вариант, который наиболее распространен и встроен во все богатые фреймворки (laravel, django, rails, spring boot, ...). В этих фреймворках до каждого теста стартует транзакция, которая в конце теста откатывается (и вложенные транзакции тоже хорошо обрабатываются). Это решение позволяет вообще не думать об очистке в процессе. Иногда делают по другому, включают автоматический truncate таблиц в базе при каждом старте тестов. Причем не ручками, а это фактически стратегия очистки, встроенная в некоторые фреймворки, где можно выбирать как чистить (или идет доп пакетом как в rails).

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

p.s. Как у вас? Мокаете или реальная база с откатом?

Ориентация на бизнес

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

Самая распространенная точка зрения, что делать для бизнеса это понять что от нас хотят, доуточнить все требования, может предложить какие-то улучшения и качественно, в срок реализовать и задеплоить. От синьора ждут, что он не просто будет делать что-то о чем попросили, но и критически на это посмотрит.

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

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

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

Например в таких ситуациях, я часто вижу, что те же разработчики, могут начать делать такую систему, даже не попытавшись посмотреть, а как оно вообще реализовано в аналогичных проектах. Можно так делать? Да сплошь и рядом, но только это не очень сильная ориентация на бизнес. Если не видеть как это делают другие, то вероятность принять правильное решение, не усложнять, не придумывать всякую фигну стремится к нулю.

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