Lighthouse & Jest: проверка того, что имеет значение

Простое дело

В недавнем докладе Джейсона Ленгсторфа Создание культуры тестирования и качества в IBM его тезис сформулирован следующим образом:

Сделайте правильные вещи ПРОСТЫМИ.

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

Его намерение в контексте разговора было примерно таким: «если вы сделаете тестирование (а это правильно) легким, то люди будут это делать».

Полностью вооружившись этой новой аксиомой, я приступил к следующему проекту, чтобы облегчить себе тестирование. Я использовал Jest для интеграционных тестов и Cypress для сквозного тестирования.

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

В основном все было в порядке с миром. Главным образом.

Правильно

Я нашел, что это удовлетворительный цикл для работы:

Скаффолд-функции › Написание тестов › Код

Я регулярно качал кулаком в победе над новым тестом, который наконец-то прошел, это был ценный выброс дофамина.

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

Отчасти я знал, что это произошло потому, что проект в целом был самоуправляемым. У меня не было продакт-менеджера, дизайнера или пользователей, которых можно было бы взять на собеседование, чтобы написать функциональные требования. Не было спецификаций для нагрузочного тестирования, не было тщательной команды контроля качества, чтобы разобрать вещи, и не было никого, к кому я мог бы повернуть экран и спросить: «Это выглядит правильно?» План тестирования в его нынешнем виде представлял собой счастливый путь каждой функции и экрана, которые я собирал, написанный и оцененный мной.

Поэтому я вернулся к аксиоме, но с другим акцентом.

СделайтеПРАВИЛЬНОЕдело простым.

У меня еще нет большого опыта в разработке программного обеспечения, так как же я должен знать, что нужно тестировать? (Сейчас я работаю над программой, по стечению обстоятельств, в Lighthouse Labs)

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

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

Войти в Маяк

Я был хорошо знаком с сайтом, размещенным в Google, который измерял скорость страницы, и подумал, что это будет хорошее место для начала.

Я нашел web.dev от Google, и он работает на инструменте под названием Lighthouse.

Я мог бы в одно мгновение проверить свой проект не только на скорость, но и на все, что делает страницу производительной:

Скорость
Доступность
Лучшие практики
Поисковая оптимизация

Lighthouse, достойный независимый аудитор, может управляться тремя способами:

На сайте, web.dev
В браузере Chrome (Инструменты разработчика › Аудит)
CLI (подробнее об этом позже)

Посмотрим, как я собрался:

Приемлемые оценки, но есть большой удар по доступности, что это значит и почему?

Сразу же у меня есть новый и простой тест, который я могу написать и запустить за считанные минуты.

Все изображения должны иметь атрибут «alt», чтобы программы чтения с экрана могли правильно отображать страницу для слабовидящих. Это очевидно важно и именно я боялся, что не буду тестировать. Я попал в платную грязь.

Давайте смоделируем простую версию того, как этот тест может выглядеть в Jest:

import { findAllByAltText } from "@testing-library/react";
test("all images have alt text", () => {
  const { container } = render(<Application />);
  expect(
    findAllByAltText(container, "")
      .not
      .toBeInTheDocument()
  );
});

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

Я могу добавить эту процедуру в свой новый цикл тестирования:

scaffold functions › писать тесты › код › запускать маяк › писать тесты › код

Однако здесь я пишу тесты дважды. Мы хотим сделать правильные вещи простыми, а делать что-то дважды непросто. Можем ли мы объединить эти две вещи?

Сделать маяк проще простого

Первое, что я хотел сделать после запуска тестов в инструментах разработки моего браузера, — заглянуть в интерфейс командной строки.

Конечно же, у Lighthouse NPM есть подробная документация. За несколько коротких команд я установил маяк, настроил быстрое приложение-заполнитель и получил файл JSON с исчерпывающей разбивкой оценок этого приложения-заполнителя. Вот как:

npm install -g lighthouse
npx express-generator
npm start
lighthouse http://localhost:3000/ --output json

Вывод этого скрипта с конфигурацией по умолчанию представляет собой файл JSON длиной в тысячи строк, который сразу же включает ценную информацию, такую как:

"accessibility": {
  "title": "Accessibility",
    ... 
  "score": 0.67
}
AND
"image-alt": {
  "id": "image-alt",
  "title": "Image elements do not have `[alt]` attributes",
    ... 
  "score": 0
}

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

Вот новая насмешка Jest о том, как может работать тестирование моей слепой зоны доступности:

const lighthouseOuptut = require('./lighthouseOutput.json')
describe("Accessibility", () => {
  test("Accessibility score is within acceptable threshold", () => {
    expect(lighthouseOutput.accessibility.score >= 0.90);
  });
  test("All Images have alt values", () => {
    expect(lighthouseOutput.image-alt.score === 1);
  });
    ...
};

Отсюда цикл возвращается к своей простой форме:

Скаффолд-функции › Написание тестов › Код

Вывод

Доступность — это только один из четырех показателей, которые я могу использовать, чтобы решить, достоин ли мой код продвигать (пять, если вы хотите развернуть свой проект как PWA). В общем, набор тестов запускает 128 различных оцениваемых тестов для любой страницы, которую вы ей бросаете. Конкретная интеграция этого инструмента и когда именно я его запущу, будет зависеть от проекта и его потребностей.

Я могу представить себе использование дочернего процесса для запуска аудита в начале всех тестов Jest.
Я могу представить запуск маяка только как последний подготовительный шаг перед фиксацией кода.
Я могу себе представить изначально слабые пороговые значения производительности для быстрых MVP и полностью отсутствующие требования SEO для инструментов, предназначенных только для внутреннего использования.
Из обширной документации я также вижу, что существуют другие методы вставки этого теста выше и ниже по течению в конвейере, которые я еще не вообразил.

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

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