Testing

The SDK ships a mock context so your tests exercise the exact shape production uses.

createMockPlatformContext

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

test('renders the building name', () => {
  const ctx = createMockPlatformContext({
    user: { ...defaultUser, roles: ['manager'] },
    building: { id: 'b1', name: 'Demo Mall' },
  });

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

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

Why use the mock vs. rolling your own

If you hand-build a PlatformContext in your tests, you can drift from the real shape — and your tests pass while production breaks. createMockPlatformContext() is built from the same types the platform injects, so:

• Type changes to the context surface break your tests at compile time (good — you find out early).
• The api client mock has the same method signatures as the real one.

Stubbing API responses

The mock's api client is overridable:

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

The self-diagnosis checklist

Before opening a support ticket, run through this — most issues resolve here:

1. Which SDK version? cat node_modules/@tv/extension-sdk/package.json | jq .version
2. Manifest valid? npx tv-sdk validate module-manifest.json
3. Events + permissions in the catalog? npx tv-sdk check-events
4. Using an @experimental symbol? Grep your imports — those can change between releases.
5. Heartbeat reporting? Check your module's dot in the Building OS sidebar.
6. Tests use createMockPlatformContext()?

If all six are clean and it still breaks, it's on the platform — file a ticket with the checklist output.