test(e2e): cover configurable destinations; stop assuming a nav item

The assertions are about the navigation, not about the setting: "the
config was saved" is the plumbing, and #69 and #72 both shipped green
under specs that measured exactly that.

Four existing specs reached a view by clicking its nav item, which since
this change is not guaranteed to exist -- Autotag is hidden by default
and Downloads is absent without a download client -- so they timed out
waiting for a locator that will never resolve. `navigateTo` dispatches
the app's own `navigate` event, which is what every nav item, card and
detail view dispatches, so it is the mechanism rather than a test-only
door. Click the item when the nav is the subject.

Closes #25
This commit is contained in:
2026-08-19 19:33:56 -04:00
parent 43d78a731a
commit c8d94a8203
5 changed files with 162 additions and 6 deletions
+6 -2
View File
@@ -1,4 +1,4 @@
import { test, expect } from '../support/fixtures.js';
import { test, expect, navigateTo } from '../support/fixtures.js';
/**
* H-19: Playlists, Downloads, Jobs, Settings and Home had a page
@@ -58,8 +58,12 @@ const TAGS: Record<string, string> = {
test.describe('every primary view says what it is', () => {
test('each one has the shared header, with a heading', async ({ app }) => {
// By event rather than by nav item: a destination is not
// guaranteed to have one any more (#25 — Downloads is absent
// without a download client), and every one of these is still a
// primary view with a header, which is what this spec is about.
for (const [view, heading, hasCount] of VIEWS) {
await app.getByTestId(`nav-${view}`).click();
await navigateTo(app, view);
await expect(app.getByTestId('main-content')).toHaveAttribute(
'data-active-view',
view,