Gustavo
d330bb5ff0
Tracks the app that was already in place (capture, treatment, outreach, WhatsApp integration, server, frontend, tests, docs) so future feature work can branch and use isolated worktrees.
84 lines
3.6 KiB
Markdown
84 lines
3.6 KiB
Markdown
# Task 10: Real Browser Acceptance and Final Verification
|
||
|
||
## Files Created/Modified
|
||
|
||
| Action | File |
|
||
|--------|------|
|
||
| Modified | `package.json` (added `test:browser` script) |
|
||
| Created | `playwright.config.mjs` |
|
||
| Created | `tests/browser/server.mjs` |
|
||
| Created | `tests/browser/campaign-pilot.spec.mjs` |
|
||
|
||
## Test Results
|
||
|
||
### `npm test` — All Node tests: **370 passed, 0 failed**
|
||
- All server, campaign, outreach, message, schedule, worker, store, auth, WhatsApp manager, and integration tests pass.
|
||
|
||
### `npm run test:browser` — Playwright tests: **42 passed, 0 failed**
|
||
- **Desktop (1440×900):** 21/21 passed
|
||
- **Mobile (390×844):** 21/21 passed
|
||
- No console errors detected during any test.
|
||
|
||
### `npm audit --omit=dev` — **0 vulnerabilities**
|
||
|
||
## Test Coverage Summary
|
||
|
||
| Test Area | Status |
|
||
|-----------|--------|
|
||
| Login with seeded admin credentials | ✅ |
|
||
| Campaign cards (status, week, limit) | ✅ |
|
||
| Separate manual/automatic limits display | ✅ |
|
||
| Campaign prepare creates queue items | ✅ |
|
||
| Preview rows show server-rendered text | ✅ |
|
||
| Per-row removal works | ✅ |
|
||
| Approval flow (transactional, scheduled, campaign→ready) | ✅ |
|
||
| Pause with explicit reason | ✅ |
|
||
| Start on paused/ready campaign with scheduled items | ✅ |
|
||
| Stage classification via API | ✅ |
|
||
| Appointment/demo scheduling form | ✅ |
|
||
| Pending replies endpoint | ✅ |
|
||
| Metrics endpoint (segmento + variant filters) | ✅ |
|
||
| UI: Pending replies section visible | ✅ |
|
||
| UI: Stage classification section renders | ✅ |
|
||
| UI: Appointment form renders | ✅ |
|
||
| UI: Metrics section with filter selects | ✅ |
|
||
| Fake provider send count remains zero | ✅ |
|
||
| Mobile viewport: cards visible, full-width controls | ✅ |
|
||
|
||
## Smoke Check Instructions
|
||
|
||
### 1. Migration v15 Verification
|
||
Start the app with `npm start`. Check `schema_migrations` table has version 15:
|
||
```sql
|
||
SELECT MAX(version) FROM schema_migrations;
|
||
```
|
||
|
||
### 2. Server-Restart Campaign Pause
|
||
Start the app, go to Campanhas tab. Verify all 3 campaigns show as `Pausada`. Hover the pause reason chip to confirm no unexpected text.
|
||
|
||
### 3. WhatsApp Status Display
|
||
Open Configurações. The WhatsApp connection state chip will show `Parado` initially. Click "Conectar / gerar QR" only when ready to pair a device.
|
||
|
||
### 4. Campaign Preview
|
||
In Campanhas tab, click "Preparar fila" on any campaign card. The queue table should appear with rendered messages and selection reasons.
|
||
|
||
### 5. Manual/Automatic Counters
|
||
Each campaign card shows `Manual: 0/10` and `Automático: 0/10`. These increment independently — manual sends count toward `Manual` only, campaign sends count toward `Automático` only.
|
||
|
||
### 6. Queue Approval
|
||
After preparing, select items and click "Aprovar fila". Approved items become `scheduled` and remaining preview items are cancelled with reason `removed_by_operator`. Campaign status changes to `Pronta`.
|
||
|
||
### 7. Pending-Reply UI
|
||
The "Respostas pendentes" section lists leads classified as `respondeu`. Use the "Classificar" button to move leads through the commercial funnel stages.
|
||
|
||
### 8. Mobile Layout
|
||
Open DevTools (F12) and toggle device toolbar (Ctrl+Shift+M). Select a mobile viewport (390×844). Verify:
|
||
- Campaign cards stack vertically
|
||
- Tables scroll horizontally
|
||
- Controls are full-width
|
||
- No layout breakage
|
||
|
||
## Safety Confirmation
|
||
- **Real provider never contacted**: All 42 browser tests use a fake WhatsApp manager that records send attempts in memory. Zero real sends occurred (asserted in test).
|
||
- **Isolated database**: Each test run uses a temporary SQLite database created via `fs.mkdtempSync` and deleted on teardown.
|