tbianchini/shopit-back
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
703158bd0674e9b155e198d668b47cbd6d01ef8d
shopit-back/app/Domains/Ticket/documentacion
History
ncoronel 703158bd06 feat(ticket): implement LoadTestTicketDatasetService for generating load test datasets 
- Added LoadTestTicketDatasetService to prepare disposable scanner tickets and generate a Postman importable dataset.
- Introduced console command `load-test🎟️prepare` for executing the dataset preparation.
- Updated README documentation with usage instructions for the load test command.
- Enhanced Postman collection generation script to include new parameters.
- Created tests for the load test command to ensure proper functionality and validation.
2026-09-03 14:15:23 -03:00
..
README.md
feat(ticket): implement LoadTestTicketDatasetService for generating load test datasets
2026-09-03 14:15:23 -03:00

README.md

Dominio Ticket

Propósito

Genera, valida, consulta y exporta entradas asociadas a compras pagadas de productos o variantes ticketables.

Modelo

  • Ticket: pertenece a tenant y usuario, y conserva referencias a compra, producto, variante y usuario escáner.
  • El nombre y la descripción se calculan dinámicamente desde el producto y la variante; los tickets no persisten una copia de esos textos.
  • ValidityTime: define ventanas absolutas o relativas de vigencia para fechas de evento y opciones de atributos.
  • ValidityTimeType: enum de estrategias de vigencia.

TicketValidityResolver deriva la vigencia desde la variante asociada. Las alternativas de un mismo atributo se combinan con OR y las dimensiones diferentes se combinan con AND. El modelo calcula si un ticket está vigente, vencido o usado, y resuelve sus fechas efectivas de inicio y fin sin persistir vigencias en el ticket.

Flujo de generación

  1. Purchase emite PurchasePaid al confirmarse el pago.
  2. GenerateTicketsForPaidPurchase atiende el evento.
  3. TicketGeneratorService crea los tickets requeridos según ítems, cantidades y vigencia.
  4. Notification envía la confirmación de compra después de la generación y adjunta los tickets cuando existen.

Datos descartables para pruebas de carga

En ambientes local, testing, staging, homo u homologation, el comando siguiente crea tickets válidos, identidades scanner con tokens Sanctum y un dataset JSON importable por Postman:

php artisan load-test:tickets:prepare loadtest-evento \
    --tickets=40000 \
    --scanners=100 \
    --owners=1000 \
    --catalog-item=123 \
    --run=evento-001

El tenant debe existir, ser exclusivo para carga y comenzar con loadtest-. Si no se indica --catalog-item, se usa el primer producto estándar del tenant con tickets habilitados. --variant es opcional; al indicarlo, su configuración de vigencia debe estar activa y ser resoluble. Sin variante, los tickets tienen vigencia irrestricta.

El archivo se escribe por defecto en storage/app/private/load-tests/ y contiene tokens secretos, por lo que no debe versionarse. Para limpiar el tenant después de la ejecución:

php artisan tenants:reset-transactions loadtest-evento --dry-run
php artisan tenants:reset-transactions loadtest-evento

Endpoints

Bajo /tenants/{tenant:codigo}, protegidos por auth:sanctum:

  • GET /tickets.
  • POST /tickets/pdf.

TicketPdfService genera la descarga y TicketResource/ValidityTimeResource definen las respuestas.

Dependencias y reglas

Depende de Purchase, Catalog, Tenant y Auth. La generación debe ser idempotente ante reintentos del evento. TicketNotAvailableException y TicketGenerationException separan indisponibilidad de errores de generación.