12-testing.md

Testing · visión

Lista de la compra tiene unitarios (Jasmine + Karma) y un job de GitHub Actions. No hay Playwright e2e: la persistencia real se cubre en unitarios de DataService con SqliteService mockeado, y CI también construye la PWA.

CI (.github/workflows/ci.yml): npm ci → lint → test:ci → build. Node 20. Sin Neon en Actions.

Siguientes documentos: unitarios · integración · e2e · CI.

13-testing-unit.md

Testing · unitarios

Runner: npm run test:ci (ChromeHeadless, un solo run). Specs en *.spec.ts.

DataService (src/app/core/services/data-service/data.service.spec.ts)

SqliteService se sustituye por un spy. Así se afirma el contrato de signals sin WASM.

it('loads products from SQLite on start', async () => {
  sqlite.getProducts.and.returnValue([
    { name: 'Leche', checked: false, quantity: 2, urgent: false, unit: 'ud', category: 'lácteos' },
  ]);
  const service = TestBed.inject(DataService);
  await service.whenReady();
  expect(service.products()[0].name).toBe('Leche');
});

it('toggles checked status and resets quantity when checked', async () => {
  await service.toggleStatus('Pan');
  expect(service.products()[0].checked).toBeTrue();
  expect(service.products()[0].quantity).toBe(1);
});

También se afirma delete por nombre y clearStorage() (llama a sqlite.clearAll() y deja products vacío).

whenReady() es obligatorio: el constructor es async (void this.load()). Sin await, el test leería [].

Otras piezas

• Tabs (tab-list, tab-pantry, tab-urgent, tabs.page) — creación del componente.
• HeaderComponent, AppComponent, directiva stop-propagation.
• NotificationService y tokens de liquid-glass (src/theme/liquid-glass.tokens.spec.ts).

14-testing-integration.md

Testing · integración

No hay un runner aparte tipo Nest + Supertest: no existe API propia. La “integración” que sí se ejecuta en CI es lint + unit + build.

Qué cubre el build en CI

npm run build compila Angular 17 a www/. Si un import de sql.js, el service worker o environment.prod.ts se rompe, el job falla antes de desplegar Netlify.

Por qué no hay TestingModule HTTP

CloudSyncService y NeonService hablan con Neon Auth/Data. Un test HTTP real exigiría secretos y correo verificado. El contrato de persistencia se afirma en unitarios con SqliteService spy; el de sync se revisa a mano en la PWA live.

Equivalente local

npm run lint
npm run test:ci
npm run build

Esa es la misma cadena que .github/workflows/ci.yml.

15-testing-e2e.md

Testing · e2e

Este repo no incluye Playwright. El flujo de compra (alta → checkbox → PDF) se valida a mano en lalistadelacompra.netlify.app y con los unitarios de DataService.

Por qué no está en CI

• La persistencia crítica (load / toggle / delete / clear) ya está en Karma.
• Un e2e de sql.js + modal Ionic + PDF añade flakiness (WASM, overlays) sin un contrato HTTP que afirmar.
• Presencia y Task Cloud sí tienen Playwright porque su UI (asistencia / tareas) es el producto que se enseña en el portfolio con un catálogo de casos.

Si se añade más adelante

Un primer spec razonable sería:

1. Abrir /despensa.
2. FAB → modal → nombre Leche → Añadir.
3. Ir a /lista y afirmar .product-name = Leche.
4. Checkbox → el ítem desaparece de pendientes.

Hasta entonces, CI verde = lint + unit + build.

16-testing-ci.md

Testing · GitHub Actions

Workflow: .github/workflows/ci.yml. Push y PR a main. Un solo job, cancel-in-progress.

- name: Setup Node.js
  uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: npm
- name: Install dependencies
  run: npm ci
- name: Run lint
  run: npm run lint
- name: Run tests (headless)
  run: npm run test:ci
- name: Build application
  run: npm run build

test:ci es ng test --watch=false --browsers=ChromeHeadless. Ubuntu Latest trae Chrome.

Por qué no hay errores de entorno

Badge en el README: CI → ese workflow.