Тесты

DMA задаёт размещение тестов относительно модулей, но не выбирает раннер, coverage-пороги и пирамиду. Правило одно: тест живёт рядом с кодом, который защищает.

Unit-тесты — разместите рядом

Файл *.test.ts (или *.spec.ts) — в той же папке, что и реализация:

features/checkout/
├── checkout.store.ts
├── checkout.store.test.ts      # store — internal
└── public/
    └── checkout-page.tsx

services/cart/public/
├── cart.ts
└── cart.test.ts                # public API сервиса

shared/lib/
├── format-currency.ts
└── format-currency.test.ts

dma check сканирует и тестовые файлы — импорты в *.test.ts / *.spec.ts попадают в тот же граф, что и production-код. Те же правила: public-api, feature-to-feature, layer-direction и остальные.

Что тестировать напрямую

Что не делать

• Импортировать внутренности чужого модуля из теста — проверка упадёт так же, как в production. Тестируйте через public/ или разместите рядом тест внутри модуля с относительный импорт.
• Корневой __tests__/ на весь проект — тесты не едут вместе с модулем при refactor.

Компонентные тесты

SFC / React component tests — разместите рядом рядом с компонентом:

features/catalog/public/
├── catalog-page.tsx
└── catalog-page.test.tsx       # опционально

Раннер на выбор: Vitest + Testing Library, @vue/test-utils, @testing-library/svelte. В examples DMA запускаемый-тесты в основном на pure TS (stores, services, lib) — без DOM-обвязка.

Integration / route tests

Тонкий корень композиции (app/, routes/) — место для проверки связки, если нужно. Чаще — отдельная папка в корне приложения:

apps/web/
├── src/
├── e2e/                        # Playwright, Cypress
└── playwright.config.ts

E2E не разместите рядом внутри features/ — они пересекают несколько модулей и роутов.

Монорепо

Unit-тесты остаются в пакете приложения (apps/web/src/...). Тесты workspace-пакета — внутри пакета. dma check анализирует один граф на корень (app или найденный пакет); графы по монорепо не склеиваются. См. Монорепо.

Примеры в репозитории

Что дальше