Тестировать или не тестировать, техническая перспектива

Определите, что вам нужно проверить, а что можно исключить.

Ramona Schwering

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

Общие рекомендации и шаблоны

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

Будь проще

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

Если свободного пространства меньше, вы можете расслабиться при тестировании. Вот почему так важно отдавать приоритет простоте тестирования. Фактически, лучшие практики тестирования JavaScript Йони Голдберга подчеркивают важность золотого правила: ваш тест должен ощущаться как помощник, а не как сложная математическая формула. Другими словами, вы должны быть в состоянии понять цель вашего теста с первого взгляда.

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

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

Проверьте, что того стоит

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

Не тестируйте детали реализации

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

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

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

Например, выбор селекторов, менее подверженных изменениям, может сделать тесты более надежными: атрибуты данных вместо селекторов CSS. Для получения более подробной информации обратитесь к статье Кента К. Доддса по этой теме или следите за обновлениями — статья на эту тему появится позже.

Издевательство: не теряйте контроль

Mocking — это широкая концепция, используемая в модульном тестировании, а иногда и в интеграционном тестировании. Он предполагает создание поддельных данных или компонентов для имитации зависимостей, которые имеют полный контроль над приложением. Это позволяет проводить изолированное тестирование.

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

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

Стоит ли мокить в сквозных тестах?

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

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

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

Особенности тестирования: что можно и что нельзя

Итак, что же включает в себя тест? И есть ли различия между типами тестирования? Давайте подробнее рассмотрим некоторые конкретные аспекты, связанные с основными типами тестирования.

Что входит в состав хорошего модульного теста?

Идеальный и эффективный модульный тест должен:

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

Что входит в состав хорошего интеграционного теста?

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

• Моделирование взаимодействия между компонентами.
• Опишите реальные сценарии и используйте макеты или заглушки.
• Учитывайте производительность.

Что входит в состав хорошего сквозного теста?

Комплексное сквозное тестирование должно:

• Копируйте взаимодействие с пользователем.
• Охватите жизненно важные сценарии.
• Охватите несколько слоев.
• Управление асинхронными операциями.
• Проверьте результаты.
• Учитывайте производительность.