EXXETA / EXXETA/trufos

test: establish UI/UX release testing for 1.0.0

Open
#956 3 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
TypeScript
Stars
49
Forks
25
Avg merge
3d 21h
Merged PRs (30d)
4

Description

## Problem

Trufos needs a repeatable UI/UX quality gate before the 1.0.0 release. Existing Vitest and Testing Library coverage does not exercise the packaged Electron application, cross-process user journeys, accessibility, or visual regressions.

## Proposed solution

Establish an initial UI/UX release-testing stack:

- add Playwright-based Electron end-to-end infrastructure
- isolate every E2E run with temporary user data
- cover critical smoke journeys for application startup, request creation/sending, persistence, settings, themes, and representative error states
- integrate automated accessibility checks for key renderer views
- add stable visual regression baselines for key light and dark views
- capture traces, screenshots, and videos on failures
- run UI/UX checks in GitHub Actions on Linux
- document exploratory UX scenarios and a manual 1.0.0 release checklist

Prefer accessible selectors (roles, labels, visible names). Add test IDs only where no stable user-facing selector exists.

## Initial delivery scope

1. Test harness and scripts
2. 5–8 critical Electron smoke tests
3. Accessibility scans for main views
4. 6–10 visual baselines
5. CI integration and failure artifacts
6. Manual UX/release checklist

## Acceptance criteria

- [ ] E2E test command launches the Electron app and uses isolated temporary state
- [ ] Critical 1.0.0 user journeys have automated smoke coverage
- [ ] Key views have automated accessibility checks with no critical or serious violations
- [ ] Stable key views have light/dark visual regression coverage
- [ ] Failed E2E runs retain useful diagnostics (trace and screenshot; video where practical)
- [ ] GitHub Actions runs UI/UX checks in a reproducible Linux environment
- [ ] Manual keyboard, zoom, screen-reader, and exploratory UX checks are documented
- [ ] Existing unit/component tests continue passing
- [ ] `yarn test`, `yarn lint`, and `yarn prettier-check` pass

## UX study scenarios

- Import a Postman collection
- Send a request containing an environment variable
- Configure authentication
- Save and reopen a request
- Understand an unreachable-server error

Record completion, time, errors/misclicks, questions, and perceived difficulty.

## Alternatives considered

- Component tests only: too little confidence across Electron IPC and persistence boundaries
- Full visual coverage: too costly and brittle for initial 1.0.0 gate
- Manual testing only: not repeatable enough for release regression protection

Contributor guide

Open the contributing guide

Research direction

Start by locating the Electron application entry point, existing Vitest and Testing Library configuration, package scripts, and GitHub Actions workflows. Define the Playwright harness around isolated temporary state, then map the listed smoke journeys and key light/dark views to stable selectors. Done means the acceptance criteria pass, failure artifacts are retained, CI is reproducible on Linux, and the manual release checklist is documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
electron, github-actions, playwright, typescript
Domain
accessibility, ci-cd, desktop, documentation, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.