Ну, какие хорошие варианты именно в плане тестирования веба. Если вот говорят, что разворачивать локально не очень релевантно, т.к. какие-то баги локально могут просто не воспроизводиться, например.
Ну, смотри.
С точки зрения достоверности - лучше всего тестировать прям на проде.
Всмысле прям вот эта же кодовая база, которая отдается пользователям, эти же сервера, та же сеть, и т.д. и т.п.
Но тестировать на проде как бы не очень удобно и поздновато.
Поэтому приходится придумывать что-то другое (или нет).
Дальше начинается типичный трейдофф "достоверность" vs "удобство" vs "деньги".
Можно поднять себе ещё одно точно такое же окружение - будет близко к проду (но не отменяет того, что где-то конфигурация будет отличаться и т.д.), но дорого (чем жирнее продакшен, тем дороже).
Можно поднимать изолированный сервер в продакшене, куда не будут пускать пользователей, кроме тестовых и теститься там.
Создает много боли, зато близко к продакшену, со своими плюсами и минусами.
Можно поднять архитектурно близкую версию продакшена.
Типа, вместо кластера мощных тачек - две и слабенькие.
Тут, вроде как, ты сохраняешь общую картину архитектуры, но при этом тратишь меньше денег.
Все ещё стоит денег, требует какого-то количества ресурсов на сопровождение и поддержку, и дополнительной работы в плане "следить, что бы было аналогично продакшену".
Зато достоверность более-менее высокая.
Не сильно удобно, но норм.
Можно поднять весь скоуп сервисов в одном условно-локальном докер-композе\кубере\етк.
Достоверность - ещё ниже, ресурсов требует ещё меньше, удобнее - вот оно всё на одной тачке.
Можно тестить локально.
Ещё более дешево и сердито (пока ты не пытаешься поднять что-то похожее на продакшен)
Дальше всё зависит от целей.
Логичный, на мой взгляд, воркфлоу - начинать с максимально простого и дешевого варианта (т.е. локально).
Если есть понимание, по каким критериям он не устраивает (и какие проблемы не решает) - двигаться на уровень выше и смотреть, как их можно решить.
