От автора: каждый разработчик знает, что он должен писать тесты, но на самом деле, многие из нас не делают этого вообще или не делают этого в достаточной мере. Проблема не в отсутствии инструментов, а в том, что у нас нет четкого понимания того, для чего предназначены эти инструменты.
Если бы я вручил вам молоток посреди поля, вы были бы довольно растеряны в том, каким должен быть ваш следующий шаг. Если бы я передал вам тот же молот в том же поле, но там были бы деревянные доски, гвозди и чертежи сарая, вы, вероятно, могли бы выяснить, что делать дальше. В этой статье я хочу дать вам начальный план того, что вы должны тестировать в приложениях Vue.js, а также инструменты, которые вам понадобятся для этого.
Что вы узнаете
В этой статье вы узнаете:
Почему мы пишем тесты? Каковы цели тестирования?
Как определить, что вы должны (и что не должны) тестировать?
Какие инструменты используются для написания этих тестов?
Цели написания тестов
Тестирование дает уверенность
Первая цель тестирования — это дать некоторую уверенность, когда вы работаете с новой или существующей кодовой базой. Если вы новичок, увидеть набор тестов — это все равно, что иметь опытного разработчика, сидящего рядом с вами и просматривающего ваш код, и убедиться, что вы находитесь на правильном пути к тому, что должен делать код.
С помощью тестов вы можете быть более уверенными при добавлении новой функции или изменении существующего кода. Интегрируя свой код в большую систему, вы можете просто запустить весь набор тестов и быть уверенным, что вы ничего не сломали.
Качество кода
Когда вы пишете компоненты, имея в виду тестирование, вы создаете изолированные, повторно используемые компоненты. Если вы начинаете писать тесты для компонентов и замечаете, что их нелегко тестировать, это явный признак того, что вы, вероятно, сможете провести реорганизацию компонентов, и это поможет легко улучшить их. Написание тестов означает меньше ошибок в коде, что приводит к повышению качества кода.
Документация
Последняя цель тестирования заключается в том, что оно помогает создать качественную документацию для вашей команды разработчиков. Когда я новичок в кодовой базе и не совсем что-то понимаю, я часто обращаюсь к тестам за рекомендациями. Тесты обычно дают мне представление о намерениях разработчика. Это также помогает мне выявить пограничные случаи, потому что это то, что вы обычно проверяете.
Определение того, что тестировать
Итак, мы понимаем ценность тестирования, но что мы должны тестировать в приложениях? Ответ для Vue.js на самом деле довольно прост: компоненты. Поскольку приложение Vue — это просто пазл из взаимосвязанных компонентов, мы должны проверить их поведение и то, как они взаимодействуют друг с другом.
Тестирование публичного интерфейса
Итак, мы знаем, что мы должны тестировать на уровне компонентов, но какую часть компонента мы должны тестировать? Хорошее место для начала — это то, что называется публичный интерфейсом. Если вы писали документацию, в которой описывалось, что делает компонент, это то, что вы должны тестировать. Вы можете представить публичный интерфейс, как различную вводимую информацию, которую может принимать компонент, и то, какими могут быть выходные данные.
Ввод
Данные: данные компонента
Свойства: свойства компонента
Взаимодействие с пользователем: пользователь нажимает кнопку
Методы жизненного цикла: mounted(), created() и т.д.
Хранилище: данные управления состоянием
Параметры маршрута: данные в маршруте
Вывод
Отображаемый вывод (Data): что отображается в DOM
События: компонент запускает событие
Изменения маршрута: при изменении маршрута
Хранилище: обновления до состояния
Связь с дочерними компонентами: изменения в дочерних компонентах
Сосредоточив внимание на публичном интерфейсе, вы меньше беспокоитесь о внутренней бизнес-логике, и не зацикливаясь на том, как работает каждая строка кода. Это может показаться нелогичным, но цель модульного тестирования состоит просто в том, чтобы убедиться, что компоненты дают ожидаемые результаты. Мы не заботимся о том, как это привело к такому результату.
Теперь, когда мы знаем, для чего мы должны выполнять тестирование, давайте рассмотрим пару базовых примеров и попробуем определить, что мы можем протестировать в каждом из них.
Пример 1: Компонент AppHeader
В этом примере у нас есть компонент, который отображает кнопку выхода из системы, если свойство loggedIn имеет значение true. Прежде чем мы продолжим, вы можете определить вход и вывод компонента?
AppHeader.vue
<template> <div> <button class="btn" v-show="loggedIn">Logout</button> </div>
</template> <script> export default { data() { return { loggedIn: false } } }
</script>
Вход
Данные (loggedIn) — это свойство данных определяет, отображается ли кнопка, так что это вход, который мы должны тестировать
Вывод
Отображаемый вывод (button) — на основе входных данных наша кнопка отображается в DOM
Этот базовый пример дает нам некоторую практику для идентификации входов и выводов, но теперь давайте рассмотрим компонент, который принимает свойства и содержит некоторую внутреннюю бизнес-логику.
Пример 2: Компонент генератора случайных чисел
Этот компонент генерирует случайное число в диапазоне свойствами между min и max, которые имеют некоторые значения по умолчанию. Можете ли вы определить вход и вывод этого компонента?
RandomNumberGenerator.vue
<template> <div> <span class="number">{{ randomNumber }}</span> <button v-on:click="generateRandomNumber">Generate Random Number</button> </div>
</template> <script>
export default { props: { min: { type: Number, default: 1 }, max: { type: Number, default: 10 } }, data() { return { randomNumber: 0 } }, methods: { generateRandomNumber() { this.randomNumber = Math.floor(Math.random() * (this.max - this.min + 1)) + this.min } }
}
</script>
Вход
Данные: randomNumber
Свойства: min и max
Взаимодействие с пользователем: button для генерации случайного числа
Вывод
Вывод визуализации (DOM): это число отображается на экране
Как мы уже видели, первая часть написания эффективных тестов — это возможность определить, какие части компонента нужно тестировать. Теперь, когда у нас есть некоторый опыт в этом, нам нужно понять, что мы не должны тестировать.
Что НЕ тестировать
Понимание того, что не нужно тестировать, является важной частью тестирования, о которой многие разработчики не задумываются, а это, в свою очередь, стоит им много времени, которое можно было бы потратить на что-то другое.
Детали реализации
При тестировании, нам не нужно заботиться о том, как определенные вещи работают, только о том, что они делают. Давайте вернемся к нашему компоненту генератора случайных чисел. Мы знаем, что мы хотим проверить, получаем ли мы случайное число, которое находится в диапазоне между значениями min и max. Вот функция, которая генерирует это случайное число.
RandomNumberGenerator.vue
generateRandomNumber() { this.randomNumber = Math.floor(Math.random() * (this.max - this.min + 1) ) + this.min;
}
Чтобы протестировать этот компонент, все, что нам нужно знать, что он генерирует случайное число от min до max. Мы не собираемся устанавливать тест, который вызывает эту функцию и следит за ее определенным поведением. Мы не заботимся о том, как это работает Math.floor(), только о том, что это дало результат, который мы ожидали. Таким образом, мы всегда можем вернуться позже и заменить логику реализации сторонней библиотекой, например, для генерации случайных чисел.
Тестирование самого фреймворка
Разработчики часто пытаются слишком много тестировать, включая внутреннюю работу самого фреймворка. Но у авторов фреймворка уже есть тесты для этого. Например, Vue делает потрясающую работу, наблюдая за изменением данных и обновляя DOM по мере необходимости. Если мы хотим проверить некоторую условную логику того, как все отображается, это нормально, но проверка того, было ли свойство данных отображено в шаблоне, — не самое эффективное использование нашего времени.
Еще одна проверенная функция — это валидация. Мы можем предположить, что если мы инициируем свойство в качестве числа, будет выдана ошибка, если мы попытаемся передать строку. Следовательно, этих тестов можно не выполнять.
Сторонние библиотеки
Когда я говорю о сторонних библиотеках, я имею в виду обе библиотеки, которые интегрируются с Vue, такие как Vue Router и Vuex, а также библиотеки вне экосистемы Vue, установленные через NPM, такие как Axios. Как и сама среда Vue, эти библиотеки уже имеют собственные тесты, поэтому нам не нужно тестировать их внутренние компоненты.
Давайте возьмем, к примеру, приложение CRUD, которое сохраняет новых пользователей. Когда новый пользователь сохраняется, Vue Router переводит посетителя на страницу со списком пользователей. Нет необходимости проверять, правильно ли работает метод push Vue Router, потому что мы знаем, что это так. Это те вещи, которые отнимают время, если мы будем беспокоиться о них без необходимости.
Заключение
В этой статье мы сделали важный первый шаг в написании эффективных тестов: определение того, что вы должны и чего вы тестировать не должны в компонентах. При таком подходе мы можем мудро сосредоточить свое время на тестировании образцов, которые необходимо протестировать. Во второй части этой серии мы применим эти знания в более практическом примере.
Автор: Dan Vega
Источник: https://www.vuemastery.com
Редакция: Команда webformyself.
