Это второй пост в серии, посвященной модульным тестам в рамках базы кода VueJS, чтобы получить более глубокое понимание того, как работают элементы в экосистеме Vue.

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

Документация VueJS великолепна, но недавно я решил копнуть еще глубже и начать изучение исходного кода Vue! Первым фрагментом кодовой базы, который я посетил, был каталог тестов. Большинство из вас наверняка слышали о Разработка через тестирование (TDD). Что ж, в этой серии я хотел бы познакомить вас с обучением через тестирование (TDL). Идея состоит в том, чтобы начать чтение модульных тестов фреймворка или библиотеки, которые вы используете, на ранней стадии, чтобы получить более глубокое понимание того, как работают отдельные функции. TDL также имеет полезный побочный эффект, поскольку он усиливает преимущества написания модульных тестов в ваших собственных проектах и ​​раскрывает надежные шаблоны тестирования.

Модульные тесты "v-if"

Во втором посте серии мы рассмотрим директиву v-if. Полностью модульные тесты можно найти здесь, но ниже мы рассмотрим их по частям. Ниже приведено начало спецификации v-if теста.

Первое, что мы замечаем, - насколько v-if похож на v-show. Они оба работают над правдивыми и ложными ценностями. Однако и ключевая разница сразу бросается в глаза. В то время как v-show устанавливает свойство CSS display: none, чтобы скрыть элемент, v-if удаляет элемент из DOM и заменяет его комментарием (<!—--->).

Это очень важное различие, которое дает нам большой намек на то, когда мы должны выбрать v-if вместо v-show и наоборот. Если мы не ожидаем, что значение, привязанное к _11 _ / _ 12_, будет часто меняться, если вообще, то v-if - лучший выбор с точки зрения эффективного рендеринга. Однако, если мы ожидаем, что это значение будет меняться довольно часто (например, переключатель), тогда нам следует склоняться к v-show. v-show работает лучше в этих ситуациях, потому что его свойство display просто переключается, а не весь блок HTML уничтожается и повторно отображается. Эта информация становится понятной, если вы сравните v-if и v-show модульные тесты перед чтением какой-либо документации. Довольно круто!

Очевидно, что переменная, связанная с v-if, может изменяться на протяжении жизненного цикла компонента. Так что же происходит, когда v-if оценивает разные значения? Следующий набор тестов объясняет это подробно!

Начало этого набора тестов показывает то, что мы могли ожидать: когда foo переключается с истинных на ложные значения, пользовательский интерфейс переключается с рендеринга span на удаление его из DOM. Если вы уже читали v-show post, все это покажется вам знакомым, поскольку в нем проверяются одни и те же значения.

Следующий набор тестов вводит директиву v-else, и мы видим, что она добавлена ​​к тому же уровню, на котором появляется v-if. Тесты идентичны тестам «правдивость» / «ложь», которые мы только что видели выше, с одним ключевым отличием. Похоже, что благодаря наличию v-else, когда значение, привязанное к v-if, является «ложным», отображается span с директивой v-else. Отлично! Поэтому вместо добавления <span v-if=”!foo”>bye</span> мы можем просто использовать директиву v-else!

Последний блок этого раздела тестов вводит еще одну директиву: v-else-if. Эта директива привязана к другой переменной, в данном случае с bar. Как мы видим из тестов: если foo "правдиво", он отображается, если foo "ложно", но bar "правдиво", bar отображается, и если оба являются "ложными", отображается элемент, содержащий v-else. Итак, эти тесты показывают, что поведение v-if можно расширить, используя v-else-if и v-else. Мы можем проверить несколько связанных переменных, и будет отображена первая из них, которая дает «правдивое» значение.

Следующий блок тестов включает директиву, с которой мы еще не столкнулись, v-for. Мы подробно обсудим эту директиву в следующем посте этой серии, но пока достаточно знать, что она используется для перебора значений, таких как элементы массива, и рендеринга элемента, в данном случае span, для каждого ценить. Эти тесты просто показывают, что v-if работает именно так, как мы ожидали внутри v-for. Отображаются «правдивые» значения, «ложные» значения удаляются из модели DOM.

Последние несколько тестов показывают, как v-if работает в сочетании с v-for. Если переменная, связанная с v-if, является «ложной», элемент, содержащий v-else, будет отображаться для каждого «элемента» в v-for. В этом случае отображаются цифры «123», а затем отображается «321» после того, как «список» перевернут.

Следующий набор тестов интересен тем, что знакомит с компонентом Vue и проверяет, как v-if работает в корне компонента. Новый экземпляр Vue создается с помощью шаблона, содержащего компонент test. Этому компоненту задается класс «test». Затем этот компонент test определяется так, чтобы свойство данных «ok» было изначально установлено на «true», и шаблон, содержащий div с идентификатором «ok», классом «inner» и v-if, привязанным к свойству данных ok.

Затем мы проверяем, что div в корне этого test компонента действительно отображается, проверяя идентификатор «ok» и оба класса «внутренний» и «тест». Затем мы меняем это свойство данных ok на «false» и снова тестируем и обнаруживаем, что компонент test был удален из DOM. Если вернуть ok обратно в «истину», наш компонент test снова отобразится. Теперь мы знаем, как комбинировать v-if с компонентами для рендеринга или удаления их из DOM. Отлично!

В этом заключительном тестовом блоке мы замечаем упоминание «ненужных патчей». Это должно напоминать нам о том, что мы скоро узнаем о некоторых оптимизациях эффективности работы с v-if.

Сначала создается пара шпионов методом createSpy Жасмин. На высоком уровне это просто слежка за методами created и destroyed, чтобы мы могли в конечном итоге проверить, сколько раз они были вызваны (если вообще). Затем создается новый экземпляр Vue со свойством данных ok, установленным на true. Также создается test компонент, который живет на сестре div по отношению к div, содержащему v-if. С этим компонентом связаны события created и destroyed.

Мы проверяем, что created был вызван один раз, как и ожидалось. Затем мы меняем ok на «ложь» и еще раз проверяем количество created вызовов. Мы обнаружили, что это все еще один, что означает, что когда div, содержащий v-if, был уничтожен, div, содержащий test, не был повторно визуализирован. Наконец, мы проверяем, не был ли этот div уничтожен, и обнаруживаем, что это не произошло из-за того, что destroyed никогда не был вызван. Это довольно круто, если вдуматься. Как говорится в комментарии к тесту:

«Когда первый div переключается, второй div следует использовать повторно, а не воссоздавать / уничтожать»

Это очень эффективный способ обновления DOM: обновлять ТОЛЬКО то, что было изменено, и повторно использовать элементы DOM, которые остались прежними.

‘V-if’ docs

Раздел v-if API docs section должен иметь для нас полный смысл теперь, когда мы изучили модульные тесты:

Как я упоминал ранее, документы VueJS превосходны, но я бы сказал, что чтение модульных тестов, лежащих в основе v-if, научило нас всему, что раскрывают документы, и многому другому всего за пару минут чтения! Кроме того, как я уже упоминал, чтение тестов научило нас, как следует писать модульные тесты и насколько они должны быть тщательными. Написание аналогичных тестов для функций в ваших собственных приложениях должно стать приоритетом для вас и вашей команды!

Следующий

В следующем посте, который скоро будет опубликован, мы подробно рассмотрим v-for через его модульные тесты!

Предыдущие сообщения

Первый пост в этой серии был посвящен v-show, и его можно найти здесь.

Если вам понравился этот пост, нажмите немного 💚 ниже, чтобы сообщить мне, что вы хотите больше этого материала! Спасибо! 🤓

Заинтересованы в построении будущего денег в Круге? Мы нанимаем!