Skip to content

Тестирование

SDK поставляет мок-контекст, чтобы ваши тесты использовали точно ту же форму, что и продакшен.

createMockPlatformContext

Значения по умолчанию описывают реалистичного оператора одного здания — менеджера эксплуатации ТРЦ, который смотрит своё здание на английском в светлой теме. Переопределяйте только то, что важно вашему тесту:

tsx
import { createMockPlatformContext } from '@tv/extension-sdk/testing';
import { PlatformProvider } from '@tv/extension-sdk/react';
import { render, screen } from '@testing-library/react';
import Shell from './Shell';

test('renders the building name', () => {
  const ctx = createMockPlatformContext({
    building: {
      id: 'b1',
      slug: 'demo-mall',
      name: 'Demo Mall',
      type: 'mall',
      timezone: 'Europe/Moscow',
    },
  });

  render(
    <PlatformProvider value={ctx}>
      <Shell />
    </PlatformProvider>,
  );

  expect(screen.getByText(/Demo Mall/)).toBeInTheDocument();
});

Переопределения поверхностные

createMockPlatformContext(overrides) принимает Partial<PlatformContext> — поверхностный, а не глубокий. Какой бы ключ верхнего уровня вы ни переопределяли, передавайте его целиком. Переопределение building требует всех полей PlatformBuilding (id, slug, name, type, timezone); частичное — ошибка типизации.

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

ts
const base = createMockPlatformContext();
const ctx = createMockPlatformContext({
  building: { ...base.building!, name: 'Demo Mall' },
  user: { ...base.user, roles: ['manager'] },
});

Почему мок, а не собственная реализация

Если вы собираете PlatformContext в тестах вручную, вы можете отойти от настоящей формы — и ваши тесты проходят, пока продакшен ломается. createMockPlatformContext() построен из тех же типов, что внедряет платформа, поэтому:

  • Изменения типов поверхности контекста ломают ваши тесты на этапе компиляции (это хорошо — вы узнаёте рано).
  • Мок клиента api имеет те же сигнатуры методов, что и настоящий.

Подмена ответов API

Правило то же: api — ключ верхнего уровня, поэтому переопределение передаёт клиента целиком. Разложите значение по умолчанию и замените нужные методы:

ts
const base = createMockPlatformContext();
const ctx = createMockPlatformContext({
  api: {
    ...base.api,
    get: vi.fn().mockResolvedValue([{ id: 's1', name: 'Unit 3B' }]),
  },
});

eventBus по умолчанию — заглушка (subscribe возвращает пустую отписку, publish резолвится). Переопределяйте его так же, когда нужно проверять опубликованные события.

Чек-лист самодиагностики

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

  1. Какая версия SDK? cat node_modules/@tv/extension-sdk/package.json | jq .version
  2. Манифест валиден? npx @tv/extension-sdk validate module-manifest.json
  3. Экспорт федерации верный? npx @tv/extension-sdk check-exposes module-manifest.json
  4. Подписки совместимы с издателями? npx @tv/extension-sdk check-pact module-manifest.json
  5. Используете символ @experimental? Просмотрите импорты — такие символы могут меняться между релизами.
  6. Сообщается ли о работоспособности (heartbeat)? Проверьте точку вашего модуля на боковой панели Building OS.
  7. Тесты используют createMockPlatformContext()?

Если все семь пунктов чистые, а проблема остаётся — она на стороне платформы; заведите обращение с выводом чек-листа.

Создано на платформе Tango Vision. Вопросы? developers@tango.vision