Модульное тестирование (?) Компонента angular 6 с помощью TestBed

При использовании TestBed вы действительно тестируете компонент или выполняете интеграционные тесты?

Создание прибора (TestBed.createComponent(AppComponent)) и вызов fixture.detectChanges() автоматически вызывает ngOnInit. Если вы хотите протестировать другой метод, теперь вы тестируете несколько единиц.

Это приводит к другому вопросу: следует ли тестировать модули или следует тестировать действия пользователей? Например, если вы тестируете метод setDimensions или должны ли вы тестировать, что, когда пользователь нажимает определенную кнопку, элемент, помимо прочего, имеет соответствующие размеры.

Я предполагаю, что первый способ тестирования был бы ближе к способу «модульного тестирования», но тогда вам все равно придется иметь дело с методами жизненного цикла вызываемого компонента. Это заставляет меня думать, что невозможно проводить модульные тесты компонента с использованием TestBed. Замещение всех методов жизненного цикла кажется смешным.

Какой бы способ тестирования вы ни выбрали, вам следует также протестировать DOM, не так ли? Тогда вы не тестируете изолированно, включая DOM api.


unit-testing integration-testing angular angular-components testbed
person maximedupre    schedule 22.05.2018    source источник
comment
Вам следует подумать об этом, прежде чем называть все, что включает связанные компоненты, интеграционным тестом stackoverflow.com/a/5357837/4793951   -  person Zircon    schedule 22.05.2018
comment
Я не уверен, что интеграционные тесты обязательно должны включать внешние части системы (например, БД) в отличие от модульного теста. Этот комментарий к ответу, на который вы мне указали, отражает мою мысль: описание модульного тестирования очень хорошее, но считали ли вы, что попарная интеграция не охватывает целые приложения, а только два тестируемых модуля. Итак, вы говорите, что тест, описанный в моем вопросе, использующий TestBed утверждение, что DOM является модульным тестом, или что, возможно, есть серая линия между модульным и интеграционным тестами и что его можно рассматривать как один из них?   -  person maximedupre    schedule 22.05.2018

Ответы (2)


arrow_upward
1
arrow_downward

Как указано в документации по Angular:

Компонент, в отличие от всех других частей приложения Angular, объединяет шаблон HTML и класс TypeScript. Компонент действительно является шаблоном и классом, работающими вместе. и чтобы адекватно протестировать компонент, вы должны проверить, что они работают вместе, как задумано.

Такие тесты требуют создания хост-элемента компонента в DOM браузера, как это делает Angular, и исследования взаимодействия класса компонента с DOM, как описано в его шаблоне.

Angular TestBed облегчает такое тестирование, как вы увидите в разделах ниже. Но во многих случаях тестирование одного класса компонента, без участия DOM, может проверить большую часть поведения компонента более простым и очевидным способом.

Итак, здесь модуль - это компонент (шаблон и класс, работающие вместе). И вы должны попробовать протестировать компонент, заглушив входные данные и зависимости.

Думаю, если вы однажды прочитаете документацию по тестированию сверху вниз, у вас есть ответы на свои вопросы.

person sabithpocker    schedule 22.05.2018
comment
Интеграционный тест предназначен для проверки того, что разные части приложения работают вместе, поэтому можно утверждать, что тестирование компонента (который представляет собой комбинацию класса и шаблона / DOM) на самом деле является интеграционным тестом. Вы действительно можете сказать, что тест - это модульный тест, потому что тестируется один модуль? Разве модульные тесты не предназначены для тестирования минимально возможного модуля? Компонент - это определенно не самая маленькая единица. Итак, субъективны ли размер / сфера применения подразделения? Что такое единица? Модуль - это единица? - person maximedupre; 23.05.2018
comment
Да, в некоторых случаях модуль - это единица. Является ли тест модульным или интеграционным, лучше понять, глядя на обоснование теста, а не на размер или сложность модуля, т.е. если основное внимание в тесте уделяется функциональности модуля или сообщение, передаваемое между модулями. Я полагаю, вы застряли на идее, что чистые функции являются единственно возможной законной единицей для тестирования. Посмотрите, как Википедия пытается определить единицы, охватывающие различные возможности - person sabithpocker; 23.05.2018
comment
Спасибо за ответ, я прочитал статью в Википедии. Если модуль может быть модулем, а компонент может быть модулем (который является частью модуля), то тестирование модуля с целью проверки его функциональности также будет проверять передачу сообщений между компонентами (также модулями). Поэтому, если вы не тестируете самый маленький блок, вы всегда будете тестировать связь между меньшими блоками. - person maximedupre; 23.05.2018
comment
Я предполагаю, что рассмотрение модулей как единиц находится на разных языках программирования, отличных от JavaScript, где сделать этот выбор тривиально. Не то, что применимо к модулям Angular. - person sabithpocker; 24.05.2018

arrow_upward
0
arrow_downward

Дополнительная информация собрана на странице Википедии о разработке через тестирование.

Для TDD модуль чаще всего определяется как класс или группа связанных функций, часто называемых модулем. Считается, что относительно небольшие размеры единиц обеспечивают критические преимущества [...]

Таким образом, модульное тестирование не обязательно проверяет наименьший возможный модуль.

Разработка через тестирование не обеспечивает достаточного тестирования в ситуациях, когда требуются полные функциональные тесты для определения успеха или неудачи из-за широкого использования модульных тестов [21]. Примерами являются пользовательские интерфейсы, программы, работающие с базами данных, а также некоторые из них, зависящие от конкретных сетевых конфигураций. TDD поощряет разработчиков помещать минимальное количество кода в такие модули и максимизировать логику тестируемого библиотечного кода, используя подделки и имитации для представления внешнего мира. [22]

Пользовательский интерфейс можно тестировать с помощью модульных тестов до определенной точки убывающей отдачи, когда полезны функциональные тесты / тесты e2e.

Модульные тесты названы так потому, что каждый тестирует одну единицу кода. У сложного модуля может быть тысяча модульных тестов, а у простого модуля - только десять. Модульные тесты, используемые для TDD, никогда не должны пересекать границы процессов в программе, не говоря уже о сетевых соединениях. Это приводит к задержкам, из-за которых тесты запускаются медленно, а разработчикам не рекомендуется запускать весь пакет. Введение зависимостей от внешних модулей или данных также превращает модульные тесты в интеграционные. Если один модуль плохо себя ведет в цепочке взаимосвязанных модулей, не так сразу понятно, где искать причину сбоя.

Я думаю, что теперь я бы определил интеграционные тесты как тесты, которые также тестируют внешние части приложения, такие как другие процессы, такие как БД или серверный API.

person maximedupre    schedule 24.05.2018