# Feature Flow

Pipeline de Estandarizacion

Templates Ops → BDD/Gherkin → Tests Backend + Frontend

## Vision General del Pipeline

### 1 Templates Ops

- Lenguaje no tecnico
- Flujos desde el usuario
- Del equipo de soporte/ops
- Captura casos borde
- Documenta problemas conocidos

### 2 BDD/Gherkin

- Archivos .feature
- Sintaxis Given/When/Then
- Specs legibles
- Fuente unica de verdad
- Mapea a ambos tipos de test

### 3 Tests

- Backend: Contratos API
- Backend: Workflows (composiciones)
- Frontend: Page Objects
- Frontend: E2E specs (Playwright)

## 1 Templates Ops

#### Estructura de la Plantilla

    ### [Nombre del Flujo]

    Tipo de usuario: Dueno / Vet / Admin
    Donde empieza: Pagina/boton/link
    Objetivo: Una oracion

    Pasos:
    1. Primera accion
    2. Segunda accion
    3. ...

    Que deberia pasar:
    - Resultado esperado

    Problemas comunes:
    - Problema 1

    Casos especiales:
    - Caso especial 1

#### Fuente

- Plantilla: album/template/ops-flow/
- Referencia: def/work_plan/21-plantilla

#### Quien Completa Esto

- Equipo de soporte (contacto diario)
- Equipo de ops (conoce workarounds)
- Producto (requerimientos)

#### Output

- Un .md por flujo
- Organizado por tipo de usuario

## 2 BDD/Gherkin

#### Archivo .feature

    Feature: Turnero - Reservar turno

      Scenario: Reservar vacuna para gato
        Given estoy en la pagina del turnero
        When ingreso direccion "Av Santa Fe 1234"
        And hago click en "Siguiente"
        Then se crea un usuario invitado

        When agrego mascota "Koshka" tipo "Gato"
        And selecciono "Vacunacion"
        Then "Consulta clinica" se agrega auto

      Scenario: Servicios filtrados por tipo
        Given agregue un gato
        Then veo vacunas felinas
        And no veo vacunas caninas

#### Palabras Clave

- Feature = una funcionalidad
- Scenario = un comportamiento
- Given = precondicion
- When = accion
- Then = resultado esperado

#### Referencia

- def/work_plan/10-flow-turnero.md
- Ejemplo completo con Gherkin, tests API, Page Objects

## 2b Organizacion de Archivos Gherkin

#### Correcto: Una Feature = Un Archivo

    features/
    ├── pet-owner/
    │   ├── registro.feature      # 6-8 escenarios
    │   ├── reservar-turno.feature # 10-15 escenarios
    │   ├── gestion-mascotas.feature
    │   └── pago.feature
    ├── veterinarian/
    │   └── ...
    └── backoffice/
        └── ...

#### Anti-patron: Un Escenario = Un Archivo

    # NO hacer esto
    features/pet-owner/registro/
    ├── registro-exitoso.feature
    ├── registro-email-invalido.feature
    ├── registro-password-corto.feature
    └── ... (docenas de archivos pequeños)

#### Por Que Multiples Escenarios por Archivo

- Feature = Capacidad - un archivo describe una capacidad con todos sus comportamientos
- Contexto junto - Background, Rules comparten contexto
- Tooling lo espera - test runners, reportes, navegacion IDE

#### Cuando Dividir

    # Escenarios por archivo:
     5-20   Normal, mantener
    20-40   Considerar dividir
    40+     Definitivamente dividir

#### Profundidad de Carpetas

- Bien: 1-2 niveles max
- Evitar: anidamiento profundo

## 3a Tests Backend

#### Estructura (amar_django_back)

    tests/contracts/
    ├── base.py          # switcher de modo
    ├── endpoints.py     # paths API (fuente unica)
    ├── helpers.py       # datos de prueba
    │
    ├── mascotas/        # tests por app
    │   ├── test_pet_owners.py
    │   ├── test_pets.py
    │   └── test_coverage.py
    ├── productos/
    │   ├── test_services.py
    │   └── test_cart.py
    ├── solicitudes/
    │   └── test_service_requests.py
    │
    └── workflows/       # composiciones
        └── test_turnero_general.py

#### Dos Modos de Test

    # Rapido (Django test client)
    pytest tests/contracts/

    # Live (HTTP real)
    CONTRACT_TEST_MODE=live pytest

#### Workflow = Composicion

    # Llama endpoints en secuencia:
    1. Check cobertura
    2. Crear pet owner
    3. Crear mascota
    4. Obtener servicios
    5. Crear solicitud

#### Archivos Clave

- endpoints.py - cambiar paths solo aca
- helpers.py - datos de ejemplo

## 3b Tests Frontend

#### Estructura (amar_frontend)

    tests/e2e/
    ├── pages/           # Page Objects
    │   ├── BasePage.ts
    │   ├── LoginPage.ts
    │   └── index.ts
    │
    └── login.spec.ts   # test E2E

#### Patron Page Object

    export class LoginPage extends BasePage {
      get emailInput() {
        return this.page.getByLabel('Email');
      }

      async login(email, password) {
        await this.emailInput.fill(email);
        await this.passwordInput.fill(password);
        await this.submitButton.click();
      }
    }

#### Ejecutar Tests

    # Todos los tests
    npx playwright test

    # Con UI
    npx playwright test --ui

    # Archivo especifico
    npx playwright test login.spec.ts

#### Prioridad de Locators

- 1. getByRole() - botones, links
- 2. getByLabel() - campos de form
- 3. getByText() - texto visible
- 4. getByTestId() - data-testid

#### Evitar

- Selectores de clases CSS
- XPath complejos

## Checklist por Feature

- Template ops completado (equipo soporte)
- Convertir a archivo .feature (spec Gherkin)
- Backend: Tests de contrato API por endpoint
- Backend: Test workflow (composicion)
- Frontend: Page Object (si es pagina nueva)
- Frontend: E2E spec (Playwright)
- Conectar a CI

Ejemplo completo: def/work_plan/10-flow-turnero.md

README Backend: amar_django_back/tests/contracts/README.md

README Frontend: amar_frontend/tests/README.md