Lack of end-to-end tests for core user journeys and installation flow across multiple database backends
- Lingua principale
- Go
- Stelle
- 15.7k
- Fork
- 1.4k
- Merge medio
- 3g 8h
- PR unite (30g)
- 7
Descrizione
### Background
Apache Answer currently relies primarily on unit tests for the Go backend and a single front-end smoke test (`ui/src/App.test.tsx`). While these tests are useful for verifying isolated functions and repository queries, they do not exercise the complete user journey or the installation process that every real deployment goes through.
### Current Situation
There is no end-to-end (E2E) testing framework or test suite in the repository. The following critical aspects of the product are only validated manually:
1. **The installation flow**
Answer is not ready to use immediately after startup. An administrator must complete an install wizard (database configuration, site settings, admin account creation) before the application is functional. This flow is currently not covered by any automated test.
2. **Core user journeys after installation**
After setup, essential flows such as user registration, login, asking a question, posting an answer, voting, accepting an answer, adding comments, searching, and changing settings in the admin panel are only checked by hand before releases.
3. **Multiple database backends**
Answer officially supports SQLite, MySQL, and PostgreSQL. Today there is no automated test that verifies the application behaves correctly on all three database engines.
Because of this gap:
- Refactors, dependency upgrades, or changes that cross the front-end/back-end boundary can introduce regressions that unit tests do not catch.
- Installation-related changes are difficult to validate safely.
- New contributors cannot confidently modify core workflows.
- Release preparation requires repeated manual smoke testing, which is slow and inconsistent.
### Why This Needs to Be Fixed
A Q&A platform’s reliability depends on the smooth operation of its full lifecycle: installation, day-to-day usage, and administration. When any of these break—especially on a supported database that was not manually tested—the product experience is compromised. E2E tests are the most practical way to guarantee that these flows work across browsers, database backends, and UI changes.
### Goal
Establish a complete, maintainable end-to-end testing path that can be run locally with a single command through Docker Compose, spinning up the full environment (Answer application + database). The test suite should:
- Cover the entire installation wizard from a fresh state;
- Validate the core user journeys after installation;
- Cover as many foundational features as technically feasible, including but not limited to user registration, login, question creation, answering, voting, accepting answers, commenting, searching, and common admin settings;
- Be executable against all three supported databases: SQLite, MySQL, and PostgreSQL.
Possible implementation approaches include using Playwright or Cypress to drive the browser, paired with a Docker Compose setup that starts the Answer backend, the front-end build, and the selected database together.
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Direzione di ricerca
Inizia esaminando i test esistenti del backend Go e ui/src/App.test.tsx, quindi confronta gli approcci Playwright e Cypress con l’ambiente Docker Compose proposto. Definisci i flussi di installazione e i percorsi utente principali da automatizzare e verifica che la suite possa essere eseguita con SQLite, MySQL e PostgreSQL tramite un unico comando locale.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- cypress, docker-compose, go, mysql, playwright, postgresql, react, sqlite, typescript
- Ambito
- databases, devops, full-stack, testing
- Tipo di issue
- Funzionalità
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Stato di attività
- Tranquilla
- Chiarezza
- Da chiarire
- Idoneità per principianti
- 25/100