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:
@@ -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,
|
||||
|
||||
Reference in New Issue
Block a user