Skip to content
This repository has been archived by the owner on Sep 25, 2024. It is now read-only.

Latest commit

 

History

History
180 lines (131 loc) · 8.49 KB

CONTRIBUTING.md

File metadata and controls

180 lines (131 loc) · 8.49 KB

GIT

Модель ветвления GIT описана здесь.

Авторелизы

Для проекта подключены авторелизы npm пакетов с помощью semantic-release. Semantic-release определяет новую версию пакета по названию коммита, а именно по его enum:

  • feat - релиз minor версии пакетов
  • bug - релиз patch версии пакетов
  • wip (work in progress) - релиз произведен не будет
  • refactor - релиз patch версии пакетов
  • doc - релиз произведен не будет
  • build - релиз patch версии пакетов
  • chore - релиз произведен не будет
  • major - будет произведен релиз major версии

Релизы основных версий пакетов

При внесении изменений в main ветку запускается релиз пакетов. При релизе происходит следующее:

  1. В create_release.yml срабатывает триггер на push в main
  2. Semantic-release определяет новую версию пакета
  3. Если новая версия пакета отличается от предыдущей, то запускается билд каждого пакета и его паблишинг в npm. Все пакеты релизяться сразу с одной версией
  4. Semantic-release генерирует changelog и создает новый release на github, добавляя в описание сгенерированный changelog
  5. После успешного паблишинга пакетов, в телеграм канал отправляется уведомление о новой версии пакетов

Формат коммитов и pull requests

Для коммитов и pull requests включен commitlint. Ниже описан формат.

Для enums feat, bug обязательно должен указываться номер задачи в jira.

Формат:

${ENUM}(SCOPE|COMPONENT_NAME|TASK): Что было сделано?

ENUM:

  • feat - добавлена новая фича. Для этого enum будет произведен релиз minor версии пакетов
  • bug - исправлена ошибка. Для этого enum будет произведен релиз patch версии пакетов
  • wip (work in progress) - промежуточные изменения
  • refactor - произведен рефакторинг. Для этого enum будет произведен релиз patch версии пакетов
  • doc - внесены изменения в .md файлы или storybook. Для этого enum релиз произведен не будет
  • build - внесены изменения в сборке пакетов. Для этого enum будет произведен релиз patch версии пакетов
  • chore - внесены изменения в настройку окружения проекта (линтеры, ci...). Для этого enum релиз произведен не будет
  • test - написаны или изменены тесты проекта

SCOPE разделены по пакетам:

  • ui
  • icons
  • fonts
  • form

COMPONENT_NAME - имя измененного компонента (наименование директорий из ui/src).

Примеры

Для feat необходимо указать номер задачи

Valid
feat(UIKIT-200,ui,Button): Добавлен props color
Invalid
feat(ui,Button): Добавлен props color

Пробел между scopes недопустим

Valid
feat(UIKIT-200,ui,Button): Добавлен props color
Invalid
feat(UI-KIT-200, ui, Button): Добавлен props color

Тестирование

Тесты в проекте пишутся с использованием vitest и react-testing-library.

Что покрывать тестами?

Тестами покрываются сущности, экспортируемые из поставляемых пакетов, к ним относятся:

  • Утилиты
  • Компоненты
  • Хуки

Тесты для утилит

Все экспортируемые утилиты должны быть покрыты тестами.

Точно должно быть покрыто тестами:

  • Базовые кейсы
  • Вариативность параметров

Тесты для компонентов

Для тестирования компонентов используется react-testing-library + jsdom.

Заметка для тестирования любого компонента

  • Проверить доступность ref (при необходимости)
  • Проверить базовый сценарий отображения
  • Проверить все измененные mui props или новые props (если props не связаны с изменением исключительно CSS)

Что тестируем

Точно должно быть покрыто тестами:

  • Функционал, написанный для компонента в репозитории. Если функционал предоставляется внешней библиотекой, то его тестировать не надо.
  • Проверка реакции компонента на пользовательские эвенты (click, focus, tab...)
  • Вариативность props

Не тестируется:

  • CSS. Используемые инструменты не умеют правильно эмулировать каскад в css. Примеры таких кейсов: проверка ширины бордера элемента, проверка цвета элемента...

Style guide для компонентного тестирования

Наименование файлов

Файлы тесты для компонентов находятся рядом с реализацией компонента:

/Button/Button.tsx
/Button/Button.test.tsx
Названия тест-кейсов

Все тесты для компонента оборачиваются в describe с названием компонента:

Button.test.tsx

describe('Button', () => {});

При тестировании пропсов необходимо указывать название тест-кейса в формате: Props:${PROP_NAME}=${PROP_VALUE}: ${DESCRIPTION}:

  • PROP_NAME - название пропса, который тестируется. Допускается вложенность пропсов (пример, Props:columns:sortable:)
  • PROP_VALUE - optional. Тестируемое значение prop
  • DESCRIPTION - описание тест-кейса
describe('Button', () => {
  it('Props:loading: отображается лоадер', () => {});

  it('Props:disabled: блокируется кнопка', () => {});

  it('Props:isActive=false: не отображается текст', () => {});

  it('Props:isActive=true: отображается текст', () => {});
});

describe('DataGrid', () => {
  it('Props:columns:sortable: отображается иконка сортировки', () => {});
});

При тестировании поведения допускается указать в начале названия тест-кейса связанные параметры, сущности, стейт компонента: ${TAG}: ${DESCRIPTION}:

describe('Autocomplete', () => {
  it('Focus: не отображается popover', () => {});
  
  it('Закрывается popover после выбора значения', () => {});
});

describe('FormSubmitButton', () => {
  it('Form-submitting: отображается лоадер', () => {});
});

Создание новых пакетов

При создании новых пакетов необходимо:

  • Релизнуть тестовую версию пакета. В противном случае CI проверки PR упадет с ошибкой (npm не позволяет создавать новые пакеты по токену)