Как построить стратегию тестирования Angular, которая находит важные недостатки

Стратегия тестирования — это план создания уверенности до того, как изменение попадёт к пользователям. Она не сводится к целевому числу тестов, пирамиде из другого продукта или проценту покрытия. Ошибки в расчёте налога, меню навигации, обратном вызове OAuth, событии аналитики, подтверждении платежа и объявлении программы чтения с экрана проявляются по-разному и требуют разных доказательств. Полезный вопрос состоит в том, какой недостаток имеет значение, где его можно найти дешевле и надёжнее всего и какая неопределённость остаётся после успешной проверки.

Составьте перечень рисков из настоящих путей, архитектуры, прежних сбоев, регуляторных требований, нагрузки и частоты изменений. Распределите между ними тесты чистой логики, отображённых компонентов, интеграций и договоров и небольшое число сквозных путей. Набор тестов должен быть предсказуемым, пригодным для диагностики и достаточно быстрым, чтобы запускаться в момент принятия решения. Современные средства Angular охватывают Vitest, TestBed, выполнение в браузере, средства проверки HTTP и испытательные оболочки компонентов, но средства лишь поддерживают стратегию, а не определяют её.

Начинайте с риска продукта и необходимых доказательств

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

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

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

Модульными тестами проверяйте решения, а не внутреннюю настройку платформы

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

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

Держите чистую логику вне компонентов и эффектов, чтобы она выполнялась без TestBed. Когда проверяется внедрение зависимостей Angular, сигналы, жизненный цикл или взаимодействие с RxJS, используйте наименьшую уместную среду Angular и проверяйте очистку вместе с результатом. Охватите отмену, ошибки, завершение, повторные вызовы, ответы не по порядку и уничтожение владельцев. Выборочно измеряйте долю обнаруженных искусственных изменений или просматривайте примеры недостатков, переживших тесты, когда покрытие строк создаёт ложную уверенность в коде с большим числом решений.

Проверяйте компоненты через их договор с пользователем

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

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

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

Проверяйте договоры API на границе

Типизированные вызовы HttpClient не проверяют JSON во время выполнения. На границе проверяйте метод, построение URL, кодирование параметров, заголовки, учётные данные, тело, отмену, предельное время, обработку состояний, правила повтора и преобразование транспортного DTO в предметную модель. Используйте испытательную серверную часть HTTP Angular, чтобы наблюдать запросы и возвращать успех, неверно сформированные данные, пустые тела, структурированные ошибки бизнеса, сетевые ошибки и поздние ответы без обращения к живому серверу.

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

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

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

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

Создавайте пользователей и данные через поддерживаемые API, но проверяемое поведение выполняйте через интерфейс. Проверяйте устойчивые результаты в интерфейсе и при необходимости через серверную проверку только для чтения. Отдавайте предпочтение ролям, подписям и испытательным идентификаторам, представляющим устойчивые понятия продукта, а не иерархии DOM или созданным классам. Ждите наблюдаемого состояния, ответа, URL или условия элемента, а не заданного промежутка времени. При отказе сохраняйте трассировку, снимок экрана, сообщения консоли, сетевые данные, серверный идентификатор связи, выпуск, браузер, размер окна и идентификатор данных.

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

Управляйте испытательными данными, личностями, временем и случайностью

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

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

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

Относитесь к нестабильным тестам как к недостатку рабочей системы

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

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

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

Постройте CI как последовательность полезной обратной связи

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

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

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

• Распределяйте доказательства по риску: сопоставьте критические результаты, виды отказов, влияние, вероятность, возможность обнаружения, стыки архитектуры, недостатки, дошедшие до пользователей, владельцев и самую узкую реалистичную границу теста.
• Проверяйте общедоступные решения и поведение: держите чистые правила вне компонентов, отображайте договоры DOM, взаимодействуйте по смыслу, проверяйте доступность и избегайте утверждений, привязанных к внутреннему устройству.
• Защищайте границы служб: проверяйте поведение HTTP, преобразование во время выполнения, схемы, обратную совместимость, порядок перехватчиков, личность, правила шлюза, значение ошибок и показательные старые данные.
• Отбирайте сквозные проверки: охватывайте решающие межсистемные пути, создавайте изолированные данные через API, ждите наблюдаемых условий, собирайте диагностические материалы и выбирайте браузеры по фактическим доказательствам.
• Управляйте непредсказуемостью: передавайте время и случайность как зависимости, изолируйте клиентов системы и личности, управляйте секретами, ограничивайте сторонние службы, устраняйте зависимость от порядка и делайте параллельное выполнение безопасным.
• Управляйте системой обратной связи: назначайте владельцев нестабильных тестов и классифицируйте их, ограничивайте изоляцию, стройте этапы CI по ценности, проверяйте кэш и выбор зависимых тестов, публикуйте полезные доказательства, измеряйте задержку и пропущенные недостатки и удаляйте устаревшие тесты.