kw/verdande
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
34 Commits 97 Branches 111 Tags
25f1e2ff82c71b46bd25a7c8f195b6ce27b8134f
Commit Graph
2 Commits
Author SHA1 Message Date
Kristian WindandClaude Opus 5 25f1e2ff82 fix(e2e): wait for the sidebar before counting its links
Release / Build and publish image (push) Failing after 9m55s
Details 
The suite passed on a laptop and failed on the runner with zero links
found. locator.all() is a snapshot and does not auto-wait: calling it
straight after goto() measures how fast the machine is, not what the page
contains.

An assertion on the first link waits for hydration, and the hrefs are
collected once and re-resolved on each pass rather than held as element
handles — navigating re-renders the sidebar, so a handle from before the
click points at an element that no longer exists.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-17 10:56:33 +02:00
Kristian WindandClaude Opus 5 1424f43a40 test(e2e): smoke tests that drive the real binary 
The brief asked for these under Definition of done and they were never
written. 610 Go tests, none of which opens a browser.

Six flows: create the first account and sign in, quick add and tick a
task off, click every link in the sidebar, open a task and edit it, walk
every settings tab, and check that the manifest's icons and the service
worker can actually be fetched. Every assertion is on rendered content
rather than on a URL — the binary serves the SPA shell for anything it
does not recognise, so toHaveURL passes on precisely the bug this exists
to catch.

The suite builds the frontend, copies it into cmd/verdande/webbuild and
starts the real binary, every run. Merely starting the server would test
whatever frontend was copied there last, which during development is
nearly always the wrong one, and a green report on code that is not
running is worse than no report.

Chromium only. A smoke test catches a build that does not work at all;
running it in three engines finds the same breakage three times.

They found four bugs the first time they ran, fixed in the commits before
this one: concurrent writes returning SQLITE_BUSY, a completed task
keeping its row, the same task landing in the list twice, and a database
failure presenting as everybody being logged out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-17 10:56:33 +02:00