Модуль 9 · Урок 36

Decomposition, catalog pipeline і tests

Складна задача стає перевірюваною, коли кожний stage має один contract. Catalog core приймає values і повертає values; DOM, network, timers та storage не входять до нього, тому fixtures відтворюють defects без browser state.

NormalizeValidateProjectRegression suite

Data flow як послідовність меж

NormalizeRaw types → canonical fields.
ValidateRequired invariants і controlled rejection.
FilterDomain predicates з explicit options.
SortCopy-based deterministic order.
ProjectМінімальна view model.
SummarizeExplicit accumulator і zero state.

Кожна function має одну причину змінюватися. View integration викликає core, але core не знає про document або UI. Це не заборона side effects назавжди — це boundary для тестованості.

Fixture-driven tests

FixtureДоводить
NormalExpected business path
EmptyZero state без exception
Invalid root/recordFailure policy
BoundaryInclusive/exclusive invariant
DuplicateЯвну deterministic policy
Missing valueRequired/default semantics

Збережіть snapshot source до/після, але не плутайте JSON text comparison з універсальним deep equality. Evidence має відповідати конкретному dataset contract.

Лабораторна і review-проєкт 2

BookFlow Catalog Logic Lab

Реалізуйте contracts, заповніть traces і test matrix, доведіть source non-mutation.

Завантажити catalog logic lab →

Після тесту відкриється проєкт 2

Створіть оригінальну catalog logic з synthetic data, окремим core, fixtures і accessible responsive view. Review — 100 балів, прийняття від 80.

Перейти до проєкту 2 →

Офіційні джерела

Практична перевірка · урок 36 з 60

Закріпіть матеріал уроку

Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.

1. Який перший stage для raw catalog data?
2. Що робить validation stage?
3. Навіщо project stage?