Кейсы как код

Кейсы можно хранить в git как Markdown-файлы (папка = сьют, файл = кейс) и синхронизировать с сервером:

pnpm tsmc pull -p SHOP -d qa/cases     # выгрузить проект в папку
pnpm tsmc push -d qa/cases --dry-run   # что изменится
pnpm tsmc push -d qa/cases             # отправить одной атомарной операцией

Push отклоняется целиком, если кейс изменён и в файле, и на сервере; pull обновляет только нетронутые файлы и кладёт серверную копию рядом с конфликтующим.

Кейсы проекта можно держать в git рядом с кодом продукта: ревьюить в pull request, искать grep’ом, править в любимом редакторе — и синхронизировать с TSMC командами tsmc pull / tsmc push.

Раскладка

qa/cases/                        ← папка, указанная в --dir
  .tsmc.json                     ← {"project": "SHOP"}: дальше --project не нужен
  Оформление заказа/             ← папка = сьют
    _suite.md                    ← id сьюта, имя (если в имени есть символы, запрещённые в папках), paths и описание
    SHOP-1 Оплата картой.md      ← файл = кейс; имя файла может быть любым
    Промокоды/                   ← вложенный сьют
      истёкший.md                ← новый кейс: id появится после push

Файл кейса

---
id: SHOP-12
version: 3
priority: high          # low | medium | high | critical
type: functional        # functional | smoke | regression | acceptance | performance | security | usability | other
status: active          # draft | active | deprecated
tags: [smoke, payments]
automation: checkout.PaymentTest.paysWithSavedCard
paths: [src/payments/**]   # код, который проверяет кейс — для подбора по изменениям
---

# Оплата сохранённой картой

## Описание

Самый частый способ оплаты: около **60 %** заказов.

## Предусловия

Пользователь вошёл, в корзине есть товар.

## Шаги

1. @shared Войти как покупатель
2. Открыть корзину
   > Корзина открыта
3. Нажать «Оплатить»
   и выбрать карту {{card}}
   > Показана форма оплаты

## Данные

| card |
| --- |
| *1234 |
| *5678 |

• В новом файле достаточно заголовка # Название; всё остальное — по умолчанию.
• id и version пишет сам tsmc. version — версия на сервере, на которой основан файл.
• Шаг — пункт нумерованного списка; продолжение действия — строки с отступом; ожидаемый результат — строки с отступом, начинающиеся с >.
• N. @shared Название — общий шаг проекта (страница «Общие шаги»): в файле одна строка, его шаги сервер подставляет при push по названию. Его текст меняют в интерфейсе — тогда меняются все кейсы с ним, а файлы при следующем pull остаются такими же: в них по-прежнему одна строка.
• ## Данные — параметры кейса: таблица Markdown, в первой строке имена параметров, дальше по строке на итерацию. В названии, предусловиях и шагах {{имя}} заменяется значением; в прогоне кейс выполняется по разу на каждую строку. Символ | внутри значения пишется как \|.
• ## Описание — о чём кейс и зачем он: контекст для того, кто его проходит. Необязателен, как и все разделы.
• Разделы можно называть и по-английски: ## Description, ## Preconditions, ## Steps, ## Data.
• Тексты — Markdown: **жирный**, *курсив*, списки и таблицы (| a | b | и строка | --- | --- |) работают в предусловиях, действиях и ожидаемых результатах; подчёркивание, шрифт и размер из редактора записываются встроенным HTML: <u>…</u>, <span style="font-size: 18px">…</span> (сохраняются только шрифты и размеры, которые предлагает редактор). Таблица в шаге пишется с отступом, как любая строка продолжения, а в ожидаемом результате — после >.
• Неизвестные разделы и текст вне разделов — ошибка: файл не будет отправлен, пока его не исправят. Так ничего не теряется молча.

Синхронизация

tsmc push отправляет всю папку одной атомарной операцией:

Состояние файла	Результат
новый файл без id	кейс создаётся, в файл записываются id и version
изменён, сервер не менялся с version	новая версия кейса
не изменён	ничего
не изменён, а на сервере новая версия	outdated — сделайте tsmc pull
изменён и в файле, и на сервере	конфликт — push отклоняется целиком
кейс на сервере, но файла нет	missing; удаляется только с --delete-missing

--dry-run показывает, что изменится, ничего не меняя.

tsmc pull приводит папку к состоянию сервера, сравнивая три версии (файл, его базовая версия, сервер): нетронутые файлы обновляются и переезжают вслед за сьютами, изменённые локально — сохраняются. Если файл изменён и там, и там, рядом кладётся копия с сервера <файл>.server.

Разрешение конфликта

1. Сравните файл с <файл>.server и перенесите нужные изменения в файл.
2. Поставьте в файле version из копии.
3. Удалите копию и выполните tsmc push.

tsmc pull --force вместо этого перезапишет локальные правки серверной версией.

Сценарий для команды

# один раз
tsmc pull -p SHOP -d qa/cases && git add qa/cases && git commit -m "Импорт кейсов"

# обычная работа: правки кейсов идут в том же PR, что и код
vim qa/cases/Оформление\ заказа/SHOP-1\ Оплата\ картой.md
tsmc push -d qa/cases --dry-run     # в CI: проверка, что push пройдёт
tsmc push -d qa/cases               # после merge в main
git commit -am "Кейсы: обновлены id и версии"

Ограничения: в тексте предусловий и шагов не стоит начинать строку с # (будет прочитано как заголовок), а строку продолжения действия — с > (будет прочитано как ожидаемый результат).