Как протестировать Toggle

Подход к тестированию компонента Toggle (переключатель)

Тестирование Toggle (переключателя, чекбокса, свитчера) — это комплексная задача, охватывающая функциональные, нефункциональные и пользовательские аспекты. Мой подход основан на модели SDLC/STLC и включает следующие ключевые направления.

1. Анализ требований и спецификаций

Перед тестированием необходимо чётко определить ожидаемое поведение:

• Состояния: Вкл (checked/true), Выкл (unchecked/false), возможно, Неопределённое (indeterminate) или Отключённое (disabled).
• Способ управления: Клик мышью, тап, клавиши (Space, Enter), перетаскивание (drag).
• Визуальное представление: Иконки, цвета, текст (On/Off, Да/Нет), анимация переключения.
• Связанная логика: Что активируется/деактивируется при переключении (показ/скрытие элементов, отправка данных, изменение настроек).
• Доступность (Accessibility): Наличие ARIA-атрибутов (role="switch", aria-checked), правильная работа с Screen Readers.

2. Разработка тест-кейсов (чек-лист)

Основные категории тестирования:

Функциональное тестирование

• Базовое переключение: Изменение состояния с Вкл на Выкл и обратно при клике/тапе.
• Различные методы ввода:

    *   Клик левой кнопкой мыши.
    *   Использование клавиши `Пробел` или `Enter` при фокусе.
    *   Для мобильных устройств — тап и свайп.

• Граничные и негативные сценарии:

    *   Повторные быстрые клики (проверка на race condition).
    *   Попытка переключения в `disabled` состоянии (элемент не должен реагировать).
    *   Взаимодействие, когда Toggle находится вне viewport (например, в скроллящемся контейнере).

• Интеграция с системой:

    *   Проверка, что изменение состояния триггерит правильные события (`onChange`, `onClick`).
    *   Сохранение состояния после перезагрузки страницы (если применимо).
    *   Синхронизация нескольких связанных Toggle (например, "Select All").

Тестирование пользовательского интерфейса (UI)

• Визуальное соответствие макетам (Pixel Perfect) во всех состояниях.
• Адаптивность: Корректное отображение на разных разрешениях и в мобильных браузерах.
• Анимация: Плавность перехода, отсутствие "разрывов" или артефактов.
• Цвета: Контрастность (соответствие WCAG), изменение цвета в разных состояниях.

Тестирование доступности (A11y)

• Навигация с клавиатуры: Элемент должен получать фокус (обычно через Tab), переключаться на Space/Enter.
• Screen Readers: Озвучивание состояния ("переключатель, включён"), роли и метки.
• ARIA-атрибуты: Проверка значений aria-checked (true/false/mixed) и aria-disabled.
• Визуальный фокус: Чётко видимая индикация фокуса (например, outline).

Кросс-браузерное и кроссплатформенное тестирование

• Проверка во всех целевых браузерах (Chrome, Firefox, Safari, Edge).
• На разных ОС (Windows, macOS, iOS, Android).
• На реальных мобильных устройствах (тач-интерфейс).

3. Автоматизация тестирования

Для регрессионного тестирования и CI/CD я бы автоматизировал ключевые сценарии.

Пример E2E-теста на Cypress:

describe('Toggle Component', () => {
  beforeEach(() => {
    cy.visit('/page-with-toggle');
  });

  it('should toggle state on click', () => {
    cy.get('[data-testid="settings-toggle"]')
      .should('have.attr', 'aria-checked', 'false')
      .click()
      .should('have.attr', 'aria-checked', 'true')
      .click()
      .should('have.attr', 'aria-checked', 'false');
  });

  it('should not toggle when disabled', () => {
    cy.get('[data-testid="disabled-toggle"]')
      .should('have.attr', 'aria-disabled', 'true')
      .click({ force: true })
      .should('have.attr', 'aria-checked', 'false');
  });

  it('should be accessible via keyboard', () => {
    cy.get('[data-testid="toggle"]').focus();
    cy.focused()
      .should('have.attr', 'aria-checked', 'false')
      .type(' ')
      .should('have.attr', 'aria-checked', 'true');
  });
});

Пример юнит-теста логики (Jest + React Testing Library):

import { render, screen, fireEvent } from '@testing-library/react';
import Toggle from './Toggle';

test('calls onChange callback when toggled', () => {
  const handleChange = jest.fn();
  render(<Toggle onChange={handleChange} />);

  const toggle = screen.getByRole('switch');
  fireEvent.click(toggle);

  expect(handleChange).toHaveBeenCalledTimes(1);
  expect(handleChange).toHaveBeenCalledWith(true); // Expecting new state
});

test('reflects initial checked state', () => {
  render(<Toggle checked={true} onChange={() => {}} />);
  expect(screen.getByRole('switch')).toHaveAttribute('aria-checked', 'true');
});

4. Интеграционное и системное тестирование

• Взаимодействие с бэкендом: Проверка, что изменение состояния отправляет корректный API-запрос (например, PATCH /settings с { "notifications": true }), и обрабатываются возможные ошибки сети.
• Состояние приложения: Проверка, что состояние Toggle правильно управляется через Redux, Context API или иной state-менеджер.
• Производительность: Наличие множества Toggle на странице не должно вызывать лагов при переключении (проверка через DevTools Performance tab).

5. Ручное и исследовательское тестирование

Несмотря на автоматизацию, важны:

• User Experience (UX): Интуитивность, расположение, понятность label.
• Сенсорное тестирование: Удобство тапа на мобильных устройствах (размер целевой области должен соответствовать рекомендациям Apple/Google).
• Визуальная регрессия: Использование инструментов типа Percy, Chromatic или Applitools для автоматического обнаружения незапланированных изменений в UI.

Ключевые метрики успеха

• 100% покрытие всех заявленных состояний и основных сценариев использования.
• Полное соответствие требованиям доступности (прохождение аудита axe-core).
• Нулевые критичные дефекты в продакшене, связанные с логикой переключения.
• Положительная обратная связь от пользователей и UX-команды.

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