Ajoute 6 scénarios Playwright qui couvrent les surfaces utilisateur
au-delà de l'auth/clients/factures : upload OCR via dropzone, listing
des plans pré-fournis, et la chaîne mailing complète end-to-end.
Import (2 tests) — import.spec.ts :
- Upload PDF via setInputFiles : MockOcrProvider extrait depuis le
filename → drafts créés → SPA redirige sur /factures/import/$batchId
→ on voit le filename listé dans les drafts
- Empty state /factures/import : dropzone + bouton "Parcourir" visibles
Plans (3 tests) — plans.spec.ts :
- Les 4 plans pré-fournis (Standard, Rapide, Patient, Ferme) sont
visibles dès le signup (provisionnés par provisionDefaultPlans)
- Clic "Créer un plan" → arrive sur le wizard /plans/nouveau
- Clic "Modifier" sur une PlanCard → page détail /plans/{slug}
Mailing (1 test, le plus précieux) — mailing.spec.ts :
- Helper helpers/mailpit.ts : clearMailpit, waitForMessageTo (poll
200ms / 10s timeout), getMessage (HTML + texte)
- Scénario : signup → onboarding → créer client avec email →
créer facture saisie manuelle → mark-paid → BullMQ worker enqueue
payment-thanks → email envoyé via SMTP → Mailpit catche →
test inspecte subject + body (numero, montant)
- Valide la chaîne complète : SPA → API → DB → BullMQ → Worker →
Mailpit, en moins de 5 s
Total après cette PR : 26 scénarios Playwright verts en 55 s.
Pré-requis runtime :
- `pnpm dev:up` (Postgres + Redis + Mailpit + MinIO)
- `pnpm e2e:setup` (création DB rubis_test_e2e + migrations)
- Mailpit accessible sur :8025 (clearMailpit l'utilise en beforeEach)
Note check-in flow : pas implémenté en E2E V1 — nécessite un endpoint
test_e2e pour générer un CheckinTask + clear token. Le flow checkin
est déjà couvert par les tests japa functional. À ajouter en PR 3 si
besoin de validation end-to-end UI.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Ajoute une couche end-to-end où un Chromium drive la SPA + API ensemble
contre une DB Postgres séparée, avec Stripe entièrement mocké au niveau
API. 6 scénarios couverts (signup + onboarding + 4 sur le billing trial).
Architecture :
- DB `rubis_test_e2e` séparée, TRUNCATE entre tests (~50 ms reset)
- Routes test-only `/__test__/*` gated par NODE_ENV=test_e2e
(reset, install Stripe mock, fire webhook, lire org state, last-org)
- Stripe mocké via __setStripeForTests — pas d'appel réseau
- Playwright spawn API + SPA automatiquement (webServer config)
- CORS étendu à test_e2e pour le cross-origin localhost:5173 → :3333
Scénarios :
- signup.spec.ts : signup → onboarding 3 étapes → dashboard (assert rubis hero)
- billing-trial.spec.ts :
• démarrer essai 14j → redirect Stripe Checkout (mock)
• fallback Free 2 factures continue l'onboarding
• webhook checkout.completed → org en trialing + trial_ends_at
• retour ?trial=cancel après abandon
• inspection DB : stripeCustomerId posé après start-trial
Scripts :
- pnpm e2e (headless)
- pnpm e2e:headed (Chromium visible)
- pnpm e2e:ui (mode interactif Playwright)
- pnpm e2e:setup (crée + migre rubis_test_e2e via docker exec)
Documentation : docs/tech/e2e-tests.md — architecture, scénarios,
extensions, CI, troubleshooting.
Limites assumées :
- L'UI Stripe Checkout (3DS, formulaire CB) n'est pas testée — externe.
Pour ça : playbook manuel docs/tech/stripe-trial-e2e-playbook.md.
- Le rendu du banner "Essai Pro" n'est pas asserté en E2E à cause de
TanStack Query staleTime — couvert par les tests vitest à la place.
État global du chantier billing : 127 tests japa + 6 Playwright + 11
vitest = couverture multi-niveaux.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ordinarthur