Фронтенд для модульного тестирования

Глава первая, где мы узнаем, что не следует тестировать во Front-End.

вступление

Если вы достаточно долго кодировали Front-End, вы, вероятно, сталкивались с раздражающим утверждением: «Front-End не может быть модульно протестирован».
Это заявление, мягко говоря, сплошная чушь. Правда в том, что Front-End можно (и нужно) тестировать. Причина, по которой разработчики избегают этого, говоря, что это невозможно протестировать, в основном связана с тем, что то, что, по их мнению, должно быть модульно-протестировано, действительно сложно, но настоящая проблема здесь не в инструментах модульного тестирования, а скорее в том, что «Они» думают, что их следует тестировать.
В этой статье я поделюсь с вами своими мыслями о том, каких типов тестов следует избегать в модульных тестах Front-End и почему, а также пару предложений по что вы можете сделать вместо этого.

Не тестируйте анимацию

Я был свидетелем случаев, когда разработчик хотел проверить, произошла ли анимация или нет, что выражалось в ожидании времени, которое должна занять анимация, а затем в проверке, находится ли анимированный элемент DOM в определенной позиции или с определенной непрозрачностью.
Здесь 2 ошибки в одном тесте. Первый - это тестовые ожидания. Он ожидает продолжительности анимации перед утверждением, и в моей книге (и по мнению других) тест не должен нарушать ограничение по времени в 250 мс, и если я жду 500 мс (или иногда больше), я серьезно замедляю скорость моего запускаются наборы тестов.
Во-вторых, тесты проверяют логику вашего кода. Позиционирование элементов - это не «логика» кода. Обычно, когда мы хотим анимировать материал, мы определяем определенный переход анимации CSS, а затем меняем класс CSS определенного элемента DOM, позволяя браузеру выполнять свои обязанности. Итак, я хочу проверить, изменился ли класс CSS или нет. Я верю, что браузер хорошо справляется со своей задачей.

Проверьте логику модификаций CSS, а не конечный результат.

Не тестируйте третьи стороны

Код, за который вы не несете ответственности и который не имеете возможности или не желаете изменять, не должен тестироваться как часть ваших тестов исходного кода.
Допустим, у вас есть библиотека, которая помогает анализировать строки. Если у вас есть функция, которая ее использует, имитируйте стороннюю библиотеку и верните от нее поддельный ответ. То, что библиотека делает внутренне, не должно вас волновать, поскольку вас интересует только то, как ваш код действует на разные результаты. Так что ... смейтесь с результатами.
Это также позволяет вам запускать тесты вне зависимости от того, присутствует ли сторонняя сторона или нет. Чем меньше ваши тесты зависят от среды, в которой они работают, тем они более детерминированы.

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

Не тестируйте браузер

Продолжая изложенную выше идею, нет смысла тестировать API браузера. Под этим я подразумеваю, что нет никакой реальной ценности в тестировании API документа или окна, как и в тестировании API собственного браузера, доступного при разработке расширений браузера. При тестировании вас интересуют результаты этих API-интерфейсов, поэтому вы также можете поиздеваться над ними.
Опять же, мы предполагаем, что браузер полностью защищен собственными разработчиками, что обычно и бывает;)

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

Не тестируйте интеграцию

Это само собой разумеется, не так ли?
Если вы выполняете модульные тесты, вы тестируете область видимости «класса» или «компонента», и только их. Если вы обнаружите, что выходите за пределы этой области, не высмеивая зависимые API, а ожидая, пока они выполнят свой реальный код, значит, вы делаете это неправильно.
Я всегда получаю предупреждение, когда вижу тест Jasmine который шпионит за функцией и вызывает ее, например, spy (myObj, ‘method’). and.callThrough () ;. Вы должны спросить: «Зачем мне вызывать эту функцию? Могу я посмеяться над его ответом? ». Во многих случаях ответ - да, что делает тест намного проще и менее зависимым от среды приложения.

Модульные тесты - это не интеграционные тесты. Убедитесь, что вы остаетесь в рамках тестируемого кода и высмеиваете внешний мир, насколько можете.
(но помните - слишком много имитаций - это запах кода, который указывает на плохой дизайн)

Не тестируйте асинхронные операции

Асинхронные операции обычно означают интеграционный тест, поскольку вы выходите за пределы тестируемой «области» и ждете ответа от другого компонента, чтобы вернуться и продолжить.
Распространенной ошибкой является создание «серверного» макета и получение от него ответа, когда его запрашивает Front-End, чтобы мы могли проверить, как наш код действует на этот ответ.
Выполнение это означает, что (A) вы полагаетесь на этот макет сервера в своих модульных тестах и ​​(B) что вы ждете ответа, который может быть отложен и замедлит ваш тест.
Оказавшись в этом месте, спросите, что именно вы пытаетесь протестировать - XHR или ваш класс обрабатывает ответ? Обычно ответ приходит позже, и если вы хотите проверить, как ваш код реагирует на ответ, просто имитируйте ответ, высмеивая XHR. На самом деле никого не волнует связь с сервером в области модульного тестирования.

Моки сервера редко нужны для модульного тестирования Front-End кода. Экономьте время и сложность тестирования, имитируя асинхронные операции

Не тестируйте пиксель

Модульные тесты Front-End отсутствуют, чтобы проверить, сдвинулся ли пиксель на 2 единицы влево. Если вы думаете, что модульные тесты могут спасти вас от повреждения пользовательского интерфейса, вы ошибаетесь. Они не для этого. Существуют и другие инструменты, которые помогают тестировать пользовательский интерфейс, но юнит-тесты предназначены для обеспечения безопасности и работоспособности нашей логики кода. Если кто-то изменил правила определенного класса CSS, это не задача модульных тестов. Избегайте проверки позиционирования, непрозрачности или каких-либо других свойств внешнего вида на ваших устройствах.

Модульные тесты проверяют логику кода, а не внешний вид пользовательского интерфейса. Вместо этого используйте подходящие инструменты, предназначенные для этого.

В заключение

Я надеюсь, что мои практики, упомянутые выше, дали вам немного больше уверенности в том, что Front-End можно и нужно тестировать на модулях. Если вы знаете, что для вас важно тестировать, а от чего следует держаться подальше, эти тесты станут частью вашего обычного Front-End программирования.

Если вам понравилось это читать, нажмите ♥ ниже. Это поможет поделиться историей с другими :)