Priority: Medium · Area: End-to-end testing · Est. effort: 8–12 h
📌 Problem
find . -name '*.spec.ts' -not -path './node_modules/*' returns 0. There is no Playwright or Cypress configuration and no browser-level test layer.
The 59 component tests are valuable, but they all render components in isolation with mocked data. Nothing verifies that the pieces work together against a running application:
- Does the app actually load and render with the real API client rather than a mock?
- Does navigation between views work?
- Does a data-loading failure surface a usable error state to a user, rather than a blank screen?
- Does the wallet connection flow complete end to end?
The gap is compounded by two known issues in this repo: useAsync — the hook every data component depends on — has no tests at all, and component tests mock it with an incomplete shape. So the integration between data loading and rendering is unverified at both the unit and the end-to-end level.
🎯 Design decision required
Do not build an exhaustive suite. Establish the layer and cover the highest-value journey. State and defend:
- Which journey first. One well-chosen path — load the app, see settlements render, handle a failed request — proves the layer works and catches the most. Argue your choice from what users actually do.
- Data strategy. Does the e2e run hit a real backend, a mocked network layer, or fixtures? A real backend gives the strongest signal and the most flakiness. Argue the trade-off, remembering the backend for this project has no persistence layer.
- Blocking or scheduled. Do e2e tests block every PR or run nightly? Argue from measured runtime and stability, not preference. Whichever you choose, state the flake policy — retry, quarantine, or hard fail.
🧩 Requirements and context
- Keep the initial suite small. A single reliable journey is worth more than ten flaky ones, and this PR's job is to make the layer exist and be trustworthy.
- Tests must be deterministic. Prove it with three consecutive runs.
- Report added CI wall-clock cost, including browser installation.
- Document how a contributor runs the suite locally.
- Error-state coverage is required, not just the happy path — a failed data load must be asserted to produce a usable UI.
- Do not weaken component tests or delete anything to accommodate this.
🛠️ Suggested execution
- Choose a framework and justify it briefly.
- Add configuration and one happy-path journey.
- Add one failure-path journey.
- Wire into CI per your blocking decision.
- Run three times; report determinism and runtime.
✅ Acceptance criteria
🚫 Out of scope
- Comprehensive journey coverage — this establishes the layer.
- Accessibility specs — separate issue, though the same layer may host them later.
- Changing component tests.
🧪 Verification
npm ci
npm run build
# plus your documented e2e invocation
npm test
📤 What your PR must include
- Your framework and journey choices with reasoning.
- Your data strategy and its trade-off.
- Blocking-vs-scheduled and flake-policy decisions.
- Determinism evidence and runtime cost.
Closes #<n>.
🔒 Security notes
End-to-end tests are the only layer that exercises the application as a user encounters it — with the real API client, real routing, and real error handling rather than mocks. On an interface displaying settlement and liquidity data, the failure worth catching is a data-loading error rendering as an empty state that a user reads as "there is nothing here" rather than "this failed to load". No current test layer can distinguish those two outcomes.
📋 Guidelines
- Minimum 95% test coverage on changed lines
- Clear documentation
- Timeframe: 96 hours from assignment
- One logical change per commit; no merge commits
💬 Join our community
Working on this, or want to sanity-check your approach before you start? Come and ask — the maintainers are there and happy to help.
Telegram: https://t.me/Grainlify
Priority: Medium · Area: End-to-end testing · Est. effort: 8–12 h
📌 Problem
find . -name '*.spec.ts' -not -path './node_modules/*'returns 0. There is no Playwright or Cypress configuration and no browser-level test layer.The 59 component tests are valuable, but they all render components in isolation with mocked data. Nothing verifies that the pieces work together against a running application:
The gap is compounded by two known issues in this repo:
useAsync— the hook every data component depends on — has no tests at all, and component tests mock it with an incomplete shape. So the integration between data loading and rendering is unverified at both the unit and the end-to-end level.🎯 Design decision required
Do not build an exhaustive suite. Establish the layer and cover the highest-value journey. State and defend:
🧩 Requirements and context
🛠️ Suggested execution
✅ Acceptance criteria
🚫 Out of scope
🧪 Verification
📤 What your PR must include
Closes #<n>.🔒 Security notes
End-to-end tests are the only layer that exercises the application as a user encounters it — with the real API client, real routing, and real error handling rather than mocks. On an interface displaying settlement and liquidity data, the failure worth catching is a data-loading error rendering as an empty state that a user reads as "there is nothing here" rather than "this failed to load". No current test layer can distinguish those two outcomes.
📋 Guidelines
💬 Join our community
Working on this, or want to sanity-check your approach before you start? Come and ask — the maintainers are there and happy to help.
Telegram: https://t.me/Grainlify