Как мы автотестируем: общее Сегодня о том, как мы подходили к автотестам для нашего (тогда) нового web-проекта, когда можно было выбирать все подходы с нуля. Будет не менее трех частей, эта - про общую философию и подходы, в следующие разы про нюансы на фронте и сервере. [Один QA/SDET в поле не воин] Один QA (эт я) не масштабируется, поэтому мы посовещались и решили, что мне важнее заняться строительством собственно культуры, фреймворками, воркшопами, исследовательским тестированием, нагрузкой и в целом быть эдаким "сторожевым псом" по качеству. Разумеется, и самому писать тесты, когда разработчикам требуется помощь. Соответственно, первое правило, которое я пушил с самого начала - мы все одинаково отвечаем за фичу с самого начала до выкатки и успешного мониторинга в проде. То есть, у нас не будет перекидывания ответственности через забор, и, что еще важнее, мы будем учиться на своих ошибках, которые все же смогли пробраться. Забегая вперед, оно действительно так и работает, и мне пора бояться сокращений, ибо, откровенно говоря, я уже не так нужен этой команде, так как они уже вышли на достаточный уровень самостоятельности. Собственно по этой причине я сейчас и учу React, чтобы начать фиксить некоторые ошибки самостоятельно. Но давайте по порядку. [Пишут все] Если я отвечаю за все вышеперечисленное, то это автоматом означает, что разработчики пишут тесты на всё, что имеет смысл покрывать. Я понимаю, что это больной момент для многих, и это один из самых частых вопросов ко мне - как сделать так, чтобы девелоперы стали писать тесты да еще и не из-под палки. Простого ответа нет, и эти рассуждения потянут еще на один отдельный пост, поэтому кратко - осознанность старших разработчиков, ваш опыт и авторитет, удобные инструменты, непрерывная работа вашими софт скиллами и один на один, и в команде. Но все же я надеюсь, что текущий тренд на то, что не писать тесты на свой код это сейчас всё более моветон. [Уровни покрытия] Основной посыл был в том, чтобы с достаточной уверенностью покрыть бизнес-логику самым быстрым видом тестов. То есть, функции покрываются юнит-тестами, компоненты в сборе/middleware - компонентными/интеграционными, и если уже точно никак без системы в сборе, то уже в этом случае идут наши слоняры E2E тесты. Да, мы смотрели в сторону тестирования контрактов, но пока не решились в это нырять. [CI/CD: must be green] Я уже писал, что при открытии Pull Request создается эфемерное окружение, где на каждый коммит в ветку запускаются все проверки, включая статические анализаторы кода. Непрошедшие тесты или проверки блокируют дальнейшие шаги, и это одна из вещей, которая заставляет команду следить за тестами не менее, чем за основным кодом. Если мы видим, что какие-то тесты сбоят и дело именно в коде самих тестов, то оно либо сразу фиксится, либо убирается из набора, но точно не существует состояния, когда команда видит отчет и думает "а, да это опять те несколько flaky тестов". Кстати, об отчетах. [Кто всё поломал] Одна из находок, которая сильно помогла сильно ускорить фидбек на падающие тесты, оказалась в персонализированных уведомлениях в общий чат: автор последнего коммита в main получает @mention себя со списком упавших тестов и меня в СС в придачу. Это может показаться что-то типа finger pointing, чего в западных компаниях не любят, но вся команда одобрила это еще на берегу, поэтому часто разработчики сами первые начают писать в тред, что они увидели из отчетов. [Автотесты на баги из прода] Баги из прода, серьезно влияющие на ревеню или на имидж - это лучший симптом того, что должно быть покрыто автотестами или мониторингом. Отсюда правило, если был такой косяк в проде - ищем какой-либо способ избежать этого в будущем. Да, не всё можно и нужно автоматизировать, но ошибки такого рода должны рассматриваться как первые кандидаты. [Заключение] Понятно, что не всё работает идеально, и всегда есть человеческий фактор, но что важно: не конкретные люди, а процессы, культура и постоянное улучшение. И это то,