Feature Flow

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

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

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

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

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