Если вы стремитесь к максимально возможному охвату кода или интеграция родительского компонента и дочернего компонента (компонентов) имеет первостепенное значение (т. Е. Если он не передает что-то дочернему компоненту правильным образом, томожет пойти очень неправильно) тогда вам обязательно нужно протестировать несколько возможных конфигураций между родительским и дочерним компонентами.
Я понимаю, что вы имеете в виду, говоря, что он не очень СУХОЙ (ив некоторых формах или случаях это действительно не СУХОЙ), но вы должны думать об этом следующим образом:
В случаях, когда вы изолируете дочерний компонент и тестируете различные конфигурации, ваши тесты должны быть в первую очередь связаны с тестированием. что эти компоненты делают с конфигурациями, когда дело доходит до DOM или тестируют границы с любыми службами и т. Д.
Если использовать ваш пример, если у меня есть компонент <Image>,Я напишу свои интеграционные тесты, чтобы утверждать его поведение, когда я даю ему определенные реквизиты или опции. Например, что произойдет, если я передам эти параметры?
<Image @width=100 @height=100 @onClick={{action "doSomething"}} />
Интеграционный тест должен проверить, что эти значения оказывают некоторое влияние на то, что он отображает, и на то, как пользователь взаимодействует с изображением. Возможно, width и height устанавливают ширину и высоту тега <img> в процентах, и нажатие на изображение должно вызывать действие, предоставляемое этому компоненту.
С другой стороныС другой стороны, зачем нам проверять, может ли мой <Carousel /> компонент отображать компонент <Image />, если у меня уже есть интеграционный тест, который проверяет все, что может сделать компонент <Image />?
Ответ таков:проверить интеграцию между этими двумя компонентами и убедиться, что родительский компонент правильно соединен с дочерними. Другими словами, необходимо убедиться, что <Carousel /> передает все без исключения опции своим дочерним компонентам правильно .
В некоторых случаях это может быть не таким уж большим делом, и в действительности яЯ думаю, что большую часть времени здесь можно пропустить, но, как я уже говорил ранее, если интеграция имеет решающее значение, вам нужно проверить, как родитель передает параметры дочерним элементам.
Чтобы проиллюстрировать, как это можно сделатьобеспечить покрытие, скажем, я подключил шаблон моего <Carousel /> компонента следующим образом:
carousel.hbs
<Image @width=50 @height=50 @onChange={{action "doSomething"}} />
Глядя на это, вы можете ясно увидеть, чтопроизошло - я хотел связать это действие как @onClick, а не @onChange. Тем не менее, все мои интеграционные тесты для <Image /> проходят, поэтому без тестирования того, как компонент <Carousel /> передает свойства своим дочерним элементам, мне бы не хватало покрытия, и у этой ошибки больше шансов попасть в производство.
Часть, которая делает ее не СУХОЙ, рассматривает интеграционный тест для родителя и вынуждена писать очень похожий код (то есть, чтобы убедиться, что при нажатии на изображение вызывается правильное действие). Иногда этого не бывает, и я думаю, что в таких сценариях интеграция может быть упущена из виду. В других случаях есть вещи, которые можно сделать, чтобы уменьшить количество дублирующегося тестового кода.
В Ember иногда передача свойства привязана к определенному имени класса для дочернего компонента (в дополнение к другим функциям),Вместо того, чтобы дублировать тест, который проверяет «правильное ли поведение дочернего компонента?», Мы можем написать интеграционный тест, который проверяет, «получил ли дочерний компонент правильное свойство?»
Например, если наш родительский компонент былвыглядит так:
carousel.hbs
<Image @someFlag=true />
Допустим, это свойство @someFlag делает следующее:
- добавляеткласс к изображению
- увеличивает размер изображения при наведении курсора мыши
- делает сетевой запрос на отчет о некоторых пользовательских показателях при нажатии на изображение
Интеграционный тест для компонента <Image /> будет проверять все эти вещи, когда @someFlag имеет значение true. Однако вместо того, чтобы дублировать этот точный тест, интеграционный тест для нашего <Carousel /> компонента может просто проверить: «имеет ли компонент <Image /> ожидаемое имя класса?»На самом деле это очень распространенный способ уменьшить количество дублирующихся тестовых кодов, которые вам нужно написать.
Конечно, есть случаи, когда вам не нужно для тестирования интеграции. Если <Carousel /> просто выдавал то, что он получил своим детям, у вас есть аргумент против написания интеграционного теста для такого рода вещей.