Модуль 8 · урок 9 з 9
Практика модуля
Практика найкоротша в плані: пʼять тестів, як просить лід. Більшість із них пишеться за десять хвилин кожен — саме тому цю ціль не варто відкладати на кінець.
КРОК 1Перевірити, що взагалі запускається
ng test має відкрити браузер і показати зелений результат на стандартному
тесті, який CLI створив разом із проєктом. Якщо щось не так — розібратись зараз,
а не разом із першим справжнім тестом.
КРОК 2Тест пайпа
Найпростіший, з нього починай. Пайп створюється через new, TestBed не потрібен.
Чотири випадки: порожнє значення, сьогодні, завтра, прострочено. Якщо пайп бере поточну дату
всередині — винеси її в параметр зі значенням за замовчуванням.
КРОК 3Тест guard
Спершу тести чистої функції рішення — пʼять коротких випадків без Angular.
Потім, за бажанням, один тест самого guard через
TestBed.runInInjectionContext з підміненими AuthService
і Router.
КРОК 4Тест стору: емісії
Головний тест модуля. Підписатись на потік, зібрати значення в масив, порівняти весь масив.
Мінімум три сценарії: початковий стан, зміна фільтра дає нову емісію, завантаження
вмикає й вимикає індикатор (тут уже fakeAsync і tick).
КРОК 5Тест стору: мутації стану
Перевір оптимістичне оновлення з відкотом при помилці. І окремо — інваріант
незмінності: змінений елемент має бути новим обʼєктом, незмінені — тими самими
(toBe, не toEqual).
КРОК 6Тест валідатора
Синхронний — тривіально, як звичайна функція. Асинхронний цікавіше: три випадки —
зайнятий код, виняток для поточного значення при редагуванні, збій сервера не блокує форму.
Скрізь fakeAsync і tick.
КРОК 7Тест чистих функцій
Бонус, який майже нічого не коштує: applyState з модуля 5,
compareBy, pickState з модуля 7. Вони вже написані як чисті
функції, тож кожен тест — це три рядки. Тут і покриття зросте само.
КРОК 8Прогін і CI
ng test --watch=false має пройти чисто, без попереджень типів.
Переконайся, що в коді немає забутих fit і fdescribe —
додай ESLint-правило jasmine/no-focused-tests. У модулі 9 цей запуск
піде в пайплайн.
ng test --watch=falseпроходить чисто.- Є 2–3 тести дата-сервісу: емісії потоків і мутації стану.
- Є 2 тести на валідацію, guard або пайп.
- Жодних попереджень типів у тестових файлах, жодного
any. - Тести не залежать від порядку виконання й проходять поодинці.
- Немає
fitіfdescribeу комітах. - Назви тестів читаються як речення.
Що сказати ліду на демо
«Тестував те, де є справжня логіка. Найцінніший тест — на стор: він перевіряє
послідовність емісій, а не одне фінальне значення, і окремо фіксує, що після помилки
потік живий і наступний запит працює. Ще один перевіряє інваріант незмінності через
toBe: незмінені елементи зберігають посилання — від цього залежить OnPush.
Асинхронний валідатор покритий трьома випадками, зокрема винятком для поточного коду
при редагуванні — цю оптимізацію легко втратити при рефакторингу. Верстку й тексти
не тестував навмисно: такі тести ламаються без реальних проблем.»
Кроки 2–3 — один вечір, вони прості. Крок 4–6 — ще один-два, там буде найбільше нового
через fakeAsync. Крок 7 — година. Разом два-три вечори на цілий модуль,
і це найдешевша ціль у всьому плані.
Далі — модуль 9, останній. Він не про код: Azure Boards, гілки, Conventional Commits, code review й читання логів CI. Якщо ти вів репозиторій за правилами з першого дня — він майже закритий, лишиться тільки звести докупи.