From c21b33467940d454bfaed37e5aa8723d4ebb10a7 Mon Sep 17 00:00:00 2001 From: katemurao19 <106687261+katemurao19@users.noreply.github.com> Date: Mon, 5 Sep 2022 19:39:07 +0300 Subject: [PATCH] Update neighborhood-agreement.md --- neighborhood-agreement.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/neighborhood-agreement.md b/neighborhood-agreement.md index a69482d..1c2e3d9 100644 --- a/neighborhood-agreement.md +++ b/neighborhood-agreement.md @@ -18,7 +18,7 @@ ------------- | ------------- Правило бойскаута | Оставь код репозитория лучше, чем он был до твоего прихода. Куда хочешь, туда и пушь | Делать PR можно в любой репозиторий, если это не запрещено внутренними политиками безопасности или соответствиями внешним стандартам. -В чужой код со своим уставом не лезь | У команд есть Coding Standard и политика Code Review. Нужно использовать Coding Standard команды, которая владеет кодом. Если Code Standard в команде отсутствует —— подсвети проблему оунеру. +В чужой код со своим уставом не лезь | У команд есть Coding Standard и политика Code Review. Нужно использовать Coding Standard команды, которая владеет кодом. Если Code Standard в команде отсутствует — подсвети проблему оунеру. Запушил в чужой код, не мержь без согласия владельца | Следуем политике Code Review команды, которая владеет кодом. Написал новый код, напиши и тесты | Тесты качественные и являются частью документации. Написал новый код, а тесты не упали? Проверь и исправь тесты | Покрываем тестами так, что баг ломает тесты. Если логику поломали, а тесты «зеленые», значит их надо исправлять. Исправляет CODE OWNER, который владеет этим функционалом. @@ -26,12 +26,12 @@ Откллоняешь на ревью, аргументируй | Оунер репозитория не может отклонить пулл-реквест без четкого объяснения причин с аргументами. Пришел тикет на ревью? Проведи его сегодня, не откладывай на завтра. | Code Review должно проходить не позже, чем на следующий день. Если сломали твой код, а ты не узнал – сам виноват | Используешь соседнее API, напиши тест, который его проверяет и скажет, что это затронуло ваш юнит. Команда — оунер результата. Всегда мониторим зависимости, которые могут поломать сервис. -Владеешь кодом – отвечаешь за его тесты и метрики | Оунишь репозиторий —— покрой тестами, метриками и необходимым логированием. +Владеешь кодом – отвечаешь за его тесты и метрики | Оунишь репозиторий — покрой тестами, метриками и необходимым логированием. *** ## Правила внесения изменений в чужой функционал -Основное правило - «Keep Going Green». Нормальное состояние билдов и тестов, в том числе UI —— зеленое, значит функционал работает и был проверен достаточно полно. +Основное правило - «Keep Going Green». Нормальное состояние билдов и тестов, в том числе UI — зеленое, значит функционал работает и был проверен достаточно полно. У нас есть принципы, согласно которым мы вносим изменения: - Всегда нужно сначала получить одобрение от владельца функционала, а потом вносить изменения. - Важно поддерживать работоспособность не только функционала, но и мониторинга, метрик и авто-тестов владельца. @@ -40,13 +40,13 @@ - Тест, который стал падать из-за изменений и не по причине бага в функциональности, должен быть актуализирован в соответствии с этими изменениями. - При расширении функционала покрытие не должно снижаться. - Чьё изменение завалило тесты на staging, тот их и чинит. -- Юнит владелеца авто-теста информируется об изменении с помощью COP —— Code Ownership Plugin. +- Юнит владелеца авто-теста информируется об изменении с помощью COP — Code Ownership Plugin. ## Ответственность владельца - Низкое покрытие тестами кода приводит к скрытию дефектов и проявлению их в продакшене. В интересах владельца кода поддерживать уровень покрытия фукнционала кода тестами в районе 50%-80%. - Если баг обнаружился через несколько релизов или несколько дней, то его исправляет владелец. -- Юнит должен понимать, что проверяет каждый автоматизированный тест, которым владеет —— DB-tests, Unit-tests, API-tests, UI-tests. +- Юнит должен понимать, что проверяет каждый автоматизированный тест, которым владеет — DB-tests, Unit-tests, API-tests, UI-tests. - Если есть старые тесты и они были «зеленые», а какие-то новые правки их сломали и автор правок не может понять причину, то это не проблема владельца тестов. Автор правок обязан исправить тесты, сколько бы времени это не заняло, либо удалять их по соласованию с владельцем. - Чтобы не тормозить общие релизные процессы, владелец обязан поддерживать работоспособность своего функционала на тестовых средах, которые используются для тестирования кросс-юнитного функционала, например, Staging. - Ответственность за сохранение функционала, его содержание в рабочем состоянии и последствия от изменений лежит на том, кто последним его правил. @@ -56,4 +56,4 @@ - Команда QA кластера выполняет ревью тестов с произвольной периодичностью для поддержания общей культуры разработки авто-тестов и наращивания стабильности и полноты автоматизации тестирования. - Соблюдаются общие требования к авто-тестам без привязки к реализации. - Проводится ревью авто-тестов для поддержания общего порядка. -- Разрабатываются рекомендации по автоматизации тестирования —— простые подходы и практики эффективной автоматизации тестирования. +- Разрабатываются рекомендации по автоматизации тестирования — простые подходы и практики эффективной автоматизации тестирования.