Стратегии тестирования при разработке избыточных хранилищ в угловых приложениях, управляемых тестами
Обычно я разрабатываю угловые приложения, управляемые тестами.
Это работает хорошо, но при использовании redux в моих проектах (в настоящее время ngrx, но также и angular/redux) есть несколько различных аспектов, которые следует учитывать при тестировании и разработке магазинов и функций/ фрактальные магазины, управляемые тестами.
Намереваться
Проблема заключается в том, чтобы найти хорошую стратегию для тестирования и разработки на основе тестов.
Есть e2e-тесты, интеграционные тесты и модульные тесты, где последние в основном тестируют статические функции и статические реактивные переменные в этом контексте.
Моя главная цель — провести разработку с помощью тестов, начиная с уровня интеграции магазинов и подмагазинов и заканчивая отдельными компонентами магазинов.
Я хочу иметь возможность изначально разрабатывать магазин без интеграции в остальную часть углового приложения.
Таким образом, сценарии, в которых переход от управления данными без избыточности или переход с одной фреймворка избыточности на другую, могут быть выполнены гладко без большого взрыва.
Различные взгляды и стратегии
Я пробовал разные стратегии с разных точек зрения.
Относитесь к редюсерам, эффектам, селекторам и создателям действий как к целостному хранилищу
Когда мы рассматриваем редукторы, эффекты, селекторы и создатели действий как просто внешние функции и переменные целостных хранилищ, достаточно протестировать их, интегрированные в инкапсулирующие хранилища.
техническая функциональность магазина указана в целом
магазины явно тестируются как один интегрированный компонент, поэтому их функциональность не просто проверяется в e2e-тестах
прямые и побочные эффекты действий указываются в одном месте.
инкапсуляция в хранилище только фиктивна. На практике нет явного класса для каждого хранилища, есть только один большой объект хранилища.
это очень объектно-ориентированная перспектива в более функциональном мире
может привести к созданию очень полных наборов интеграционных тестов
никаких «настоящих» юнит-тестов
Относитесь к редьюсерам, эффектам, селекторам и создателям действий строго как к отдельным компонентам, которые тестируются изолированно.
Мы рассматриваем редукторы, эффекты, селекторы и создатели действий как отдельные и полностью независимые компоненты и тестируем их изолированно.
небольшие компактные наборы тестов, ориентированные на соответствующие функции и реактивные переменные
влияние действий указано отдельно для ответственности различных компонентов
реальные модульные тесты
взаимодействие различных компонентов только что проверено в e2e-тестах
Спецификация воздействия действий распределена по нескольким наборам тестов
высокая сплоченность компонентов магазина видна только в файловой структуре и их конфигурации в модулях ng.
Относитесь к редюсерам, эффектам, селекторам и создателям действий как к отдельным компонентам, которые тестируются отдельно, но интегрированы.
Мы относимся к редюсерам, эффектам, селекторам и создателям действий как к отдельным компонентам, тестируем их тоже отдельно, но интегрированно в сторах.
небольшие, бережливые тесты, фокусирующиеся на соответствующих функциях и реактивных переменных
влияние действий определяется отдельно от ответственности различных компонентов
компоненты магазинов тестируются комплексно, поэтому их работоспособность не просто проверяется в e2e-тестах
принадлежность к конкретному магазину также видна в интеграционных тестах
Спецификация воздействия действий распределена по нескольким спецификациям
при первом взгляде на название спецификации кажется, что это модульные тесты, но это интеграционные тесты
никаких «настоящих» юнит-тестов
Вывод
Сначала я начал с сочетания первого и второго подходов, но вскоре избыточность между интеграционным тестом магазина и тестами его отдельных компонентов заставила меня остановиться и переосмыслить свою точку зрения и этот подход.
Моя вторая мысль заключалась в том, чтобы относиться к компонентам хранилищ как к аутсорсинговым функциям и реактивным переменным и больше тестировать их только инкапсулированными в интеграционных тестах.
Не говоря уже о модульном тестировании, компоненты хранилища все еще казались немного необычными, но разработка хранилища избыточности, основанная на тестах, теперь казалась действительно хорошей.
Кроме того, из-за того, что тесты структурированы во вложенных костюмах для каждого действия, результаты тестов также были действительно хорошими. Я сразу увидел, какие эффекты и побочные эффекты вызывает каждое действие.
Но, по крайней мере, когда я расширил магазин несколькими различными видами побочных эффектов, интеграционный тест стал слишком большим.
Итак, я остановился на последнем подходе, который, наконец, показался мне хорошим компромиссом между его плюсами и минусами для осмысленного тестирования функций/фрактальных хранилищ.
Буду очень рад прочитать о ваших мнениях и подходах к этому вопросу.
Первоначально опубликовано на сайте maimart.de 24 июля 2018 г.
