Saltar a contenido

Reglas de testing — Frontend

data-testid

Formato: gk-<componente>-<elemento>-<variante> (variante opcional).

  • Componente: nombre corto en kebab (ej. pin-modal, dashboard, time-control).
  • Elemento: rol o nombre (ej. input, submit-btn, place-card).
  • Ejemplos: gk-pin-modal-input, gk-dashboard-place-card, gk-time-control-clock-in-btn, gk-reports-period-day.

Añadir en: - Botones de acción principal (login, clock-in, guardar, aprobar). - Inputs críticos (PIN, filtros). - Listas o cards que se usen en flujos E2E (selección de empleado, de lugar).

❌ Prohibido 

<ion-button (click)="clockIn()">Fichar</ion-button>
✅ Correcto 
<ion-button data-testid="gk-time-control-clock-in-btn" (click)="clockIn()">Fichar</ion-button>

Qué testear primero

  1. Servicios: AuthService (login/register/me), ApiService (mock HttpClient), WebSocketService (suscripción/desuscripción).
  2. Guards e interceptors: AuthGuard, AuthInterceptor (token en cabecera, 401).
  3. Páginas críticas: al menos un test que cargue el componente con mocks (Dashboard, TimeControl, Reports) y compruebe que no rompe.

Specs

  • Cada componente o página nuevo debe tener *.spec.ts que instancie el componente con TestBed y mocks mínimos. Mínimo: should create.
  • Para servicios: inyectar el servicio, mockear dependencias (HttpClient, etc.) y testear métodos que tengan lógica (no solo delegación trivial).

Convención en CI

  • Tests unitarios: ng test (o equivalente). Ejecutar en pipeline antes de merge.
  • E2E: si se añaden, usar el mismo prefijo gk- en data-testid para selectores estables.