Редуктори
Само бързо опресняване на това какво е редуктор, преди да преминем към тестване и кодиране. „Документацията на Redux“ все още е страхотна, всъщност покрива „единичните тестове наистина добре“, дори не е нужно да четете тази публикация. За да го обобщим, редукторът е чиста функция, която приема предишното състояние и действие и връща следващото състояние.
Ако се интересувате да научите как да тествате асинхронни редуциращи действия, проверете
Чисти функции
Тъй като това е „чиста функция“, лесно се тества. Това е функция, която не предизвиква странични ефекти; дадени на един и същ вход, винаги ще връща същия изход; не разчита на външно състояние.
Какво да тествам
Обикновено редукторът се състои от първоначално състояние и команда за превключване, за да се справи с всяко действие. Обичам да разделям магазина си на различни подмагазини и да имам отделни редуктори за всеки подмагазин. Понякога един превключвател/случай може да се справи с няколко действия, тъй като бизнес логиката е една и съща и резултатът трябва да е същият. Някои примерни GET_POST и UPDATE_POST трябва да актуализират един и същ магазин и да дадат същия резултат.
Важно е да тествате редуктори. Това е мястото, където трябва да се случи бизнес логиката и където се формира ново състояние на приложението въз основа на външен (API) или вътрешен отговор.
Стереотипния
Както всеки единичен тест, той започва с шаблонна настройка и писане на празни тестове, само за да очертае какво трябва да се тества. Обичам да тествам първоначалното състояние и след това всеки превключвател/случай в редуктора, за да видя дали action.payload ще произведе очаквания магазин. Ако спрете и помислите за това - това е просто.
Добавяне на тестове и фиктивни данни
Оттук нататък можем просто да започнем да попълваме тестовете един по един. Също така обичам да създавам макетни файлове и да съхранявам отговора на API по време на тестване. Така че мога да тествам срещу „реални“ данни. Тази стратегия разкри няколко случайни промени на API, при които отговорът беше променен без никакво предупреждение. Вместо да обвиняваме някого, можем просто да погледнем фиктивните данни и да видим какво се очаква от предния край.
Наличието на модулни тестове за всички редуктори ще предотврати всякакви проблеми, свързани с глобалното състояние на приложението. Това е особено полезно, ако има много различни извиквания на API и всяко извикване ще промени състояние. Лесно е да нарушите цялото състояние на приложението с малък рефакторинг, без да го осъзнавате.
