Как сочетаются TDD и декларативное программирование?

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

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

Что вы получите из этой статьи?

  • Краткий обзор того, что такое декларативное программирование, а что нет.
  • Как писать параметризованные тесты на JavaScript.
  • Определение подходящего времени для использования таких тестов.
  • Плюсы и минусы написания параметризованных тестов.

Декларативно - в чем дело?

Я убедил себя использовать декларативную парадигму, когда начал писать на React, но что в этом особенного?

Декларативную парадигму обычно сравнивают с императивной парадигмой. В императивном программировании мы сосредотачиваемся на том, как мы хотим достичь нашей цели. С другой стороны, декларативное программирование больше касается того, чего мы хотим достичь. Тайлер МакГиннис в своей статье на эту тему привел отличный пример:

«Я рядом с Wal-Mart. Как мне отсюда добраться до твоего дома? »

Настоятельный ответ: выйдите из северного съезда со стоянки и поверните налево. Выезжайте на I-15 North, пока не дойдете до съезда с 12-й улицы. Сверните направо с выезда, как будто собираетесь в Ikea. Идите прямо и на первом светофоре поверните направо. Продолжайте движение на следующий светофор, затем поверните налево. Мой дом № 298.

Заявительный ответ: мой адрес: West Immutable Alley, 298, Иден, Юта 84310.

Как писать параметризованные тесты

Я подготовил репозиторий GitHub с некоторым шаблонным кодом, написанным на JavaScript. Для начала посмотрим, как будет выглядеть тест, когда все параметры указаны внутри тестов:

Эти тесты написаны в обязательном порядке. В каждом тесте я выполнял одни и те же шаги:

  • Создайте книгу.
  • Проверьте, действительна ли книга.
  • Присвойте результат переменной.
  • Проверьте, соответствует ли результат ожидаемому.

Теперь давайте посмотрим, как мы можем отделить параметры в каждом тесте от тестовой логики:

Как видите, мы оставили только тестовую логику, которая проверяет, действительна ли созданная книга, но все параметры находятся в другом файле JSON:

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

Существует множество библиотек, позволяющих писать параметризованные тесты (например, jest-each) . Использовать эту конкретную библиотеку довольно просто. Вы можете указать тестовые примеры с помощью массива массивов, где каждый массив является новым тестовым набором, а каждый элемент в массиве является другим аргументом тестовой функции:

Или используя строку шаблона вместо массива массивов:

Это решение кажется идеальным для более простых случаев, но для более сложных тестов, когда нам нужно внедрить некоторые службы или репозитории, лучше использовать файл JSON с указанными там тестовыми примерами из-за разделения и повышенной читабельности.

Когда использовать параметризованные тесты

Использование

Конечно, это зависит от обстоятельств. Вы не ожидали другого ответа, не так ли? Наилучшим сценарием для таких тестов является ситуация, когда у нас есть много тестовых примеров для одного теста - как в приведенном выше примере, где мы тестировали проверку какой-то книги для разных данных. Другим примером может быть репозиторий, в котором мы хотим проверить каждый из методов CRUD на предмет различного набора данных, чтобы убедиться, что мы касаемся каждого случая.

Не использовать

С другой стороны, вам не следует использовать параметризованные тесты в ситуациях, когда вы тестируете один набор данных. Отделить данные от теста было бы излишним.

Плюсы / минусы параметризованных тестов

Плюсы

  • Создайте тест один раз, а затем добавляйте только новые тестовые случаи.
  • Логика тестирования отделена от тестовых случаев.
  • Файл JSON с тестовыми примерами можно легко передать другим членам команды, не беспокоясь о том, что кто-то нарушит ваши тесты.
  • Благодаря проверке схемы JSON тесты могут быть переданы членам команды, которые менее технически подготовлены (например, ручным тестерам).
  • Они следуют принципу СУХОЙ.

Минусы

  • Отделение логики теста от параметров теста требует дополнительной работы.
  • Излишек для тестов, требующих проверки всего в нескольких случаях.
  • Дополнительный файл с тестовыми случаями (не требуется).

Заключение

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

Я надеюсь, что эта короткая статья оправдала то, что я обещал вначале.

Спасибо за прочтение!

Twitter: k_wdowik