FTS examples: новый вид предметных unit-тестов

Пример находится рядом с правилом и использует ubiquitous language:

пример «Большая покупка постоянного клиента»
  дано сумма равна 20000
  дано «постоянный клиент» равен да
  ожидается результат равен 3000

Команда запускает все примеры модели:

fts test discount.fts --pretty

Несовпадение ожидания возвращает ненулевой exit code. Поэтому FTS example — не пример в документации, а исполняемый acceptance-level unit test чистого правила.

Что это даёт junior-разработчику

Junior не пишет генератор формы вручную «после какого-то шага». Он:

1. описывает поля;
2. добавляет конкретный пример;
3. запускает fts check и fts test;
4. передаёт каноническую модель готовому адаптеру формы или таблицы.

Готовая утилита ничего не угадывает: именно структура FTS становится входом адаптера.

Что это даёт QA и аналитику

Пример читается без знания тестового framework. При этом он версионируется, проходит в CI и исполняет ту же семантику, что production-вызов. Аналитик может предложить пример в pull request, а разработчик проверить, что он типизирован и не противоречит свойствам.

Что всё равно тестировать обычным framework

FTS examples не заменяют:

• интеграционные тесты базы и брокера;
• HTTP contract tests;
• component tests поведения React;
• E2E пользовательского пути;
• нагрузочные и security tests.

Они закрывают точную область: детерминированную предметную политику.

Генерация node:test

fts generate discount.fts --out generated

Появятся fts.utilities.ts и fts.utilities.test.ts. Сгенерированные тесты полезны, если репозиторий хочет запускать всё одним test runner, собирать coverage или публиковать обычный JS-артефакт.

Упражнение

Для одного правила напишите минимум три примера: ниже порога, точно на пороге и выше порога. Добавьте пример, который должен нарушить свойство, и обсудите: является ли это ожидаемым результатом или ошибкой модели?

Дальше: Node.js