Стратегии за тестване при разработване на редуцирани магазини в ъглови приложения, управлявани от тестове
Обикновено разработвам ъглови приложения, управлявани от тестове.
Това работи добре, но когато използвам redux в моите проекти (в момента ngrx, но също и angular/redux), има няколко различни аспекта, които трябва да се имат предвид при тестване и разработване на магазини и функции/ фрактални магазини, управлявани от тестове.
възнамерявам
Въпросът е да се намери добра стратегия за тестване и развитие, водена от тестове.
Има e2e-тестове, интеграционни тестове и модулни тестове, като последните тестват предимно статични функции и статични реактивни променливи в този контекст.
Основното ми намерение е да стимулирам развитието чрез тестове от ниво на интеграция на магазини и подмагазини, до отделните компоненти на магазините.
Искам да мога първоначално да разработя магазина без интеграция в останалата част от ъгловото приложение.
Така че сценарии, при които мигрирането от управление на данни без редуциране или мигрирането от една редуцирана рамка към друга може да се извърши гладко, без голям удар.
Различни гледни точки и стратегии
Опитах различни стратегии от различни гледни точки.
Отнасяйте се към редукторите, ефектите, селекторите и създателите на действия като към холистичен магазин
Когато третираме редукторите, ефектите, селекторите и създателите на действия като просто външни функции и променливи на холистични магазини, достатъчно е да ги тестваме интегрирани в капсулиращи магазини.
техническата функционалност на магазина е уточнена като цяло
магазините са изрично тествани като един интегриран компонент, така че тяхната функционалност не е гарантирана само в e2e-тестовете
преките ефекти и страничните ефекти от действията са посочени в една единствена точка.
капсулирането в магазин е само фиктивно. На практика няма изричен клас за всеки магазин, има само един голям магазин обект.
това е много обектно ориентирана перспектива в един по-функционален свят
може да доведе до много изчерпателни тестови пакети за интеграция
няма „истински“ единици тестове
Отнасяйте се към редукторите, ефектите, селекторите и създателите на действие стриктно като към отделни компоненти, които са тествани изолирани
Ние третираме редукторите, ефектите, селекторите и създателите на действия като отделни и напълно независими компоненти и ги тестваме изолирани.
малки, лесни тестови пакети, фокусирани върху съответните функции и реактивни променливи
въздействието на действията е посочено отделно за отговорността на различните компоненти
реални единици тестове
взаимодействието на различните компоненти е просто тествано в e2e-тестовете
спецификацията на въздействието на действията се разпространява в множество тестови пакети
високата кохезия на компонентите на магазина се вижда само във файловата структура и тяхната конфигурация в модулите ng
Третирайте редукторите, ефектите, селекторите и създателите на действия като отделни компоненти, които се тестват отделно, но интегрирани.
Ние третираме редукторите, ефектите, селекторите и създателите на действия като отделни компоненти, тестваме ги също отделно, но интегрирани в магазините.
малки, щадни тестове, фокусирани върху съответните функции и реактивни променливи
въздействието на действията е посочено разделено на отговорността на различните компоненти
компонентите на магазините се тестват интегрирани, така че тяхната функционалност не се гарантира само в e2e-тестовете
принадлежността към определен магазин се вижда и в интеграционните тестове
спецификацията на въздействието на действията се разпространява в множество спецификации
на пръв поглед името на спецификацията изглежда така, че са единични тестове, но са интеграционни тестове
няма „истински“ единици тестове
Заключение
Първо започнах с комбинация от първия и втория подход, но скоро излишъкът между интеграционния тест на магазина и тестовете на неговите отделни компоненти ме накара да се задържа и да преосмисля моята гледна точка и този подход.
Втората ми мисъл беше да третирам компонентите на магазините като просто възложени функции и реактивни променливи и вече да ги тествам само капсулирани в интеграционните тестове.
За да не тестваме единици, компонентите на магазините все още се чувстваха малко необичайни, но тестово задвижваното развитие на магазина redux сега се чувстваше наистина добре.
Освен това, поради структурирането на тестовете във вложени костюми за всяко действие, резултатът от тестовете също беше наистина добър. С един поглед видях какви ефекти и странични ефекти предизвиква всяко действие.
Но поне когато разширих магазина с множество различни видове странични ефекти, тестът за интеграция стана твърде голям.
Така че завърших с последния подход, който най-накрая се почувствах като добър компромис между неговите плюсове и минуси, за да тествам функциите/фракталните магазини по смислен начин.
Ще се радвам да прочета вашите мнения и подходи по този въпрос.
Първоначално публикувано в maimart.de на 24 юли 2018 г.
