Одним из важнейших аспектов при написании тестов является ясность и читаемость их названий. Название теста должно не только четко передавать его суть, но и давать представление о том, что именно проверяется в рамках этого теста. Хорошо выбранное имя делает код более понятным и облегчает поддержку, что особенно важно в крупных проектах с множеством тестов.
Конкретность и четкость Название теста должно быть достаточно специфичным, чтобы было понятно, что именно проверяется. Общие формулировки вроде “works correctly” или “does the thing” не дают представления о том, что именно происходит в тестируемом компоненте. Вместо этого следует использовать более точные формулировки.
Пример:
testLoginFunction()should display error message when login failsИспользование глаголов в настоящем времени Описание того, что должно происходить, обычно начинается с глагола в настоящем времени. Это помогает сделать название теста активным и четким. Важно также избегать использования избыточных слов, таких как «должен» или «проверка», так как глагол сам по себе может достаточно ясно выразить суть.
Пример:
test if submit button worksdisables submit button when form is invalidСогласованность Важно придерживаться единого стиля на протяжении всех тестов. Это особенно актуально для крупных командных проектов. Например, если вы выбрали структуру “should” + “verb”, то стоит использовать её во всех тестах, чтобы они имели одинаковую форму.
Пример:
should render button и
is form disabled?should render button и
should disable form when invalidОписание контекста Тесты часто зависят от состояния приложения или компонентов. Указание этого контекста в названии теста поможет понять, при каких условиях выполняется проверка. Это особенно важно, когда тесты затрагивают множество состояний или взаимодействий, где контекст играет ключевую роль.
Пример:
should show modalshould show modal when user clicks on 'add item' buttonИспользование описательных имен функций В тестах с несколькими шагами часто используются вспомогательные функции для имитации действий пользователя, например, кликов или ввода текста. Их названия должны также быть описательными и чёткими, чтобы другие разработчики могли легко понять, что именно делает каждая функция.
Пример:
clickBtn()clickAddItemButton()Указание на возможные ошибки или исключения Названия тестов должны также учитывать возможные исключения и ошибки, которые могут возникнуть при выполнении действия. Это важно для случаев, когда компонент должен корректно обрабатывать не только стандартные сценарии, но и неожиданные.
Пример:
should show notificationshould show error notification when network request failsУчет асинхронности При работе с асинхронными операциями тесты должны чётко указывать, что проверка будет происходить в асинхронном контексте. Например, если тестируетесь запросы к серверу или анимации, следует добавить указание на асинхронность в описание теста.
Пример:
should fetch data from APIshould fetch data from API when component mountsТипичная структура имени теста включает в себя несколько ключевых частей:
Каждая часть может быть представлена фразой или коротким описанием, что позволяет легко понять логику теста, не углубляясь в код. Например:
should disable submit button when form is invalidЗдесь видно, что:
Несмотря на то, что можно создать довольно подробные и полные имена для тестов, важно не увлекаться излишними подробностями, которые усложняют восприятие. Названия должны быть короткими, но при этом информативными. Избегайте слишком длинных фраз и слишком сложных конструкций. Имена тестов должны оставаться читаемыми.
Пример плохого имени:
should throw error in case of missing parameter when user tries to submit a form with invalid data and the server response indicates a 500 error
Такое имя слишком длинное и тяжёлое для восприятия. Лучше разбить такие тесты на несколько более мелких, каждый из которых будет проверять отдельный аспект ошибки.
Для улучшения структуры и ясности в названии тестов, полезно следовать лучшим практикам, рекомендуемым используемыми тестовыми библиотеками и фреймворками, такими как Jest и React Testing Library. Эти инструменты предоставляют собственные методы и рекомендации, чтобы поддерживать тесты на высоком уровне качества и улучшать их читаемость.
Например, в React Testing Library часто используется паттерн “выводить, что должно быть на экране” для проверки интерфейса. В этом контексте название теста будет сфокусировано на поведении компонента и его взаимодействии с пользователем, а не на внутренних деталях реализации.
Неправильно:
test('test button click', () => {
const { getByText } = render(<MyComponent />);
fireEvent.click(getByText('Submit'));
expect(getByText('Loading...')).toBeInTheDocument();
});Это название не дает представления о том, что именно происходит в тесте. Оно очень общее и не отражает, чего ожидается от компонента.
Правильно:
test('should show loading state when submit button is clicked', () => {
const { getByText } = render(<MyComponent />);
fireEvent.click(getByText('Submit'));
expect(getByText('Loading...')).toBeInTheDocument();
});Здесь уже понятно, что именно проверяется — переход компонента в состояние загрузки при клике на кнопку.
Таким образом, создание понятных, лаконичных и точных названий для тестов — это важный шаг на пути к улучшению качества кода и его удобства для чтения. Хорошо написанные тесты легко поддерживать и интегрировать в большой проект, особенно когда работают несколько разработчиков и требуется четкость в коммуникации.