4 хака для написания фронтенд-тестов в 10 раз быстрее (возможно!)

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

Хак 1: Используйте Testing Playground

Наверное, первый совет в этой статье — использовать библиотеку тестирования. Я не стал выделять ее в отдельный пункт, потому что она и так очень популярна. Но если вы еще не используете ее, обязательно воспользуйтесь!

Юнит-тестирование с помощью Testing Library действительно просто и интуитивно понятно. Несмотря на это, все еще может быть сложно найти правильные запросы или понять, почему элемент не сопоставляется.

На помощь приходит Testing Playground.

Testing Playground позволяет вам визуализировать компонент в песочнице, обеспечивая прямую визуальную обратную связь с компонентом. Она также позволяет взаимодействовать с визуализированным компонентом, чтобы придумать лучшие запросы для выбора элементов. И, как и в библиотеке Testing Library, все, что она делает, направлено на обеспечение доступности (a11y), поэтому в процессе использования она обучает вас важности a11y и лучшим практикам.

Существует множество способов использования Testing Playground, включая расширение для хрома и приложение для браузера.

Лучший способ, который я нашел и который абсолютно экономит мне время — это вызов screen.logTestingPlaygroundURL() прямо из самого тестового блока. Обычно я делаю это сразу же после рендеринга компонента, просто для того, чтобы разобраться в его устройстве и понять, с какими частями компонента мой тест может взаимодействовать.

Хак 2: Используйте test.todo

Пожалуйста, не набрасывайтесь на меня, но я пробовал Test Driven Development и мне это не понравилось. Как и анархизм, я думаю, что в теории это звучит потрясающе, но я обнаружил, что это фактически замедлило мой цикл разработки, когда я попытался реализовать это.

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

Теперь я использую test.todo в Jest для записи того, что я собираюсь протестировать в процессе планирования и создания функции (большое спасибо Карлу за то, что он впервые предложил мне эту идею!).

Мой обычный процесс выглядит примерно так. Сначала я фиксирую требования, сформулированные для меня моим замечательным владельцем продукта (привет Биз!) в форме test.todo, как список дел. Затем, по мере создания и столкновения с другими побочными ситуациями и важными областями тестирования, я добавляю их в test.todo. Таким образом, когда приходит время тестирования, я уже продумал многое из того, что собираюсь тестировать, и с меньшей вероятностью пропущу тестирование крайних случаев или важных функциональных требований.

Простой пример для test.todo для следующего компонента <UserDetails />:

import React from "react";

export interface User {
  firstName: string;
  lastName: string;
  username: string;
  emailAddress: string;
  SEN: string;
}

export interface ShowHideUserDetailsProps {
  showDetails: boolean;
  user: User;
}

const UserDetails = ({ showDetails, user }: ShowHideUserDetailsProps) => (
  <>
    {showDetails ? (
      <div>
        <h1>User Details</h1>
        <ul>
          <li>{user.firstName}</li>
          <li>{user.lastName}</li>
          <li>{user.username}</li>
          <li>{user.emailAddress}</li>
          <li>{user.SEN}</li>
        </ul>
      </div>
    ) : (
      <div>
        <h1>Privacy Protected</h1>
      </div>
    )}
  </>
);
export default UserDetails;
Вход в полноэкранный режим Выйти из полноэкранного режима

Может быть следующим:

describe('<UserDetails />', () => {
  test.todo('Should show user details when show details is true');

  test.todo('Should NOT show user details when show details is false');
});
Вход в полноэкранный режим Выйти из полноэкранного режима

Хак 3: Используйте функции конструктора

Раньше я создавал объекты для каждого теста, чтобы подражать значениям для тестирования. Затем я писал другой компонент, который использовал тот же объект, и снова подражал ему. Должен быть лучший способ, думал я. И Мэтт Смит из FinoComp познакомил меня с ним.

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

export interface User {
  firstName: string;
  lastName: string;
  username: string;
  emailAddress: string;
  SEN: string;
}

export interface ShowHideUserDetailsProps {
  showDetails: boolean;
  user: User;
}
Вход в полноэкранный режим Выход из полноэкранного режима

У вас может быть функция построителя, которая выглядит следующим образом:

export const buildShowHideUserDetailsProps = (overrides?: Partial<ShowHideUserDetailsProps>): ShowHideUserDetailsProps => {
  const defaultShowHideUserDetailsProps = {
    showDetails: false,
    user: {
      firstName: "Jazmyne",
      lastName: "Jacobs",
      username: "Kylee_Skiles37",
      emailAddress: "Rashawn13@gmail.com",
      SEN: "SEN-123456"
    }
  };

  return { ...defaultShowHideUserDetailsProps, ...overrides};
};
Вход в полноэкранный режим Выход из полноэкранного режима

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

Хак 4: Используйте инструмент для издевательства над типами Typescript

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

Каждый раз, когда я создавал очередной объект для тестирования, я смотрел на свои типы Typescript и думал: а не может ли что-то посмотреть на это и сделать это за меня? Это направило меня на поиски решения, и я был так рад, что нашел intermock, который является инструментом командной строки, делающим именно это. Хотя он все еще находится в процессе разработки и имеет некоторые ограничения, я нашел его очень полезным при написании тестов.

Однако использование комбинации CLI и копирования/вставки из терминала показалось мне немного громоздким. Как бы сделать это еще проще, подумал я.

Введите мое расширение VSCode, Emulative. Просто выберите имя вашего типа, выполните команду через палитру команд в VSCode, и вы сможете использовать Emulative для создания объектов Typescript, объектов Json или вышеупомянутых функций конструктора из типов Typescript. Они автоматически копируются в буфер обмена, но обычные объекты также могут быть отправлены в новый scratch-файл.

Но подождите, это еще не все! Там, где я работаю в Easy Agile, у нас есть куча свойств, с которыми мы работаем из Jira и которые не могут быть точно представлены string или number. С помощью Emulative вы можете установить пары ключ/значение, которые будут перезаписывать любые совпадающие свойства, найденные в ваших типах.

Выражаю благодарность Easy Agile за предоставленное время, ресурсы и поддержку во время Inception Week для работы над Emulative!

Ну, на этом у меня все, надеюсь, вы найдете некоторые из этих советов и приемов полезными для ускорения тестирования фронт-энда.

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


Привет 👋 Я Джон, разработчик и психолог в Easy Agile. Когда я не создаю продукты, которые нравятся клиентам, вы обычно можете найти меня в море с женой и дочерью, проводящим слишком много времени, мучаясь над размером помола кофе или выгуливая моего золотистого ретривера Нормана.

Если вы хотите узнать больше о Inception Weeks или поболтать о чем-либо другом, связанном с agile, разработкой программного обеспечения (или серфингом!), свяжитесь со мной в Twitter.

Оцените статью
devanswers.ru
Добавить комментарий