Files
supabase/apps/studio/tests
cc540ff302 feat(studio): add safe theme colour controls (#49804)
## What kind of change does this PR introduce?

Feature.

## What is the current behaviour?

Studio Appearance preferences only select a theme mode. The underlying
theme colours cannot be adjusted, and the existing proof of concept
allowed unsafe combinations and introduced a bespoke Slider variant.

## What is the new behaviour?

- Preserves the existing System, Dark, Light, and Classic Dark theme
options. Classic Dark remains a fixed preset.
- Adds four theme colour controls using the existing Supabase Slider
unchanged. Each control presents a consistent 0 to 100 scale mapped to
bounded light and dark ranges.
- Previews colour changes while dragging and persists them once the
interaction finishes, including rapid pointer gestures.
- Stores light and dark overrides separately, validates stored values,
clamps legacy values, and removes overrides that return to their shipped
defaults.
- Adds concise descriptions for Chroma, Contrast, Surface, and Elevation
step, with a scoped Reset action shown only when the active theme
differs from its defaults.
- Keeps Slider in a stable shared chunk so production builds do not
create a circular dependency between generated UI chunks.

| Before | After |
| --- | --- |
| <img width="1448" height="1284" alt="CleanShot 2026-09-15 at 14 33
53@2x"
src="https://github.com/user-attachments/assets/d55151c7-b2a9-40c6-9468-e77ae685ac38"
/> | <img width="1454" height="1958" alt="CleanShot 2026-09-15 at 17 48
47@2x"
src="https://github.com/user-attachments/assets/9d302e67-76cc-4341-948c-81713dea2e93"
/> |

## To test

1. Open `/account/me` and scroll to Appearance.
2. Switch between System, Dark, Light, and Classic Dark. Confirm the
same four modes remain available in the account theme menu.
3. Confirm Classic Dark retains its existing appearance and does not
show theme colour controls.
4. In System, Dark, or Light, move each Theme colors slider to both
ends. Confirm the dashboard previews the change, remains readable, and
the theme cards do not shift or remount.
5. Reload the page and confirm colour changes persist separately for
Light and Dark.
6. Return all sliders to their defaults, or select Reset, and confirm
the Reset action disappears.
7. In System mode, change the operating system theme and confirm each
resolved mode restores its own colour settings.

---------

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com>
2026-09-17 10:33:59 +10:00
..
2026-09-11 12:17:49 +08:00

UI Testing Notes

Rules

  • All tests should be run consistently (avoid situations whereby tests fails "sometimes")

  • Group tests in folders based on the feature they are testing. Avoid file/folder based folder names since those can change and we will forget to update the tests.

Examples: /logs /reports /projects /database-settings /auth

Custom Render and Custom Render Hook

customRender and customRenderHook are wrappers around render and renderHook that add some necessary providers like QueryClientProvider, TooltipProvider and NuqsTestingAdapter.

Generally use those instead of the default render and renderHook functions.

import { customRender, customRenderHook } from 'tests/lib/custom-render'

customRender(<MyComponent />)
customRenderHook(() => useMyHook())

Mocking API Requests

To mock API requests, we use the msw library.

Global mocks can be found in tests/lib/msw-global-api-mocks.ts.

To mock an endpoint you can use the addAPIMock function. Make sure to add the mock in the beforeEach hook. It won't work with beforeAll if you have many tests.

beforeEach(() => {
  addAPIMock({
    method: 'get',
    path: '/api/my-endpoint',
    response: {
      data: { foo: 'bar' },
    },
  })
})

API Mocking Tips:

  • Keep mocks in the same folder as the tests that use them
  • Add a test to verify the mock is working

This will make debugging and updating the mocks easier.

test('mock is working', async () => {
  const response = await fetch('/api/my-endpoint')
  expect(response.json()).resolves.toEqual({ data: { foo: 'bar' } })
})

Mocking Nuqs URL Parameters

To render a component that uses Nuqs with some predefined query parameters, you can use customRender with the nuqs prop.


customRender(<MyComponent />, {
  nuqs: {
    searchParams: {
      search: 'hello world',
    },
  },
})

<Popover> vs <Dropdown>

When simulating clicks on these components, do the following:

// for Popovers
import userEvent from '@testing-library/user-event'
await userEvent.click('Hello world')

// for Dropdowns
import clickDropdown from 'tests/helpers'
clickDropdown('Hello world')