rckrdmrd/workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
main
workspace/projects/erp-suite/apps/verticales/construccion/docs/97-adr/ADR-010-testing-strategy.md
rckrdmrd ea1879f4ad feat: Initial workspace structure with multi-level Git configuration 
- Configure workspace Git repository with comprehensive .gitignore
- Add Odoo as submodule for ERP reference code
- Include documentation: SETUP.md, GIT-STRUCTURE.md
- Add gitignore templates for projects (backend, frontend, database)
- Structure supports independent repos per project/subproject level

Workspace includes:
- core/ - Reusable patterns, modules, orchestration system
- projects/ - Active projects (erp-suite, gamilit, trading-platform, etc.)
- knowledge-base/ - Reference code and patterns (includes Odoo submodule)
- devtools/ - Development tools and templates
- customers/ - Client implementations template

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-08 10:44:23 -06:00

1.7 KiB
Raw Permalink Blame History

ADR-010: Testing Strategy

Estado: Aceptada Fecha: 2025-11-24 Responsable: Architecture-Analyst Proyecto: ERP Construccion

Contexto

El proyecto requiere testing robusto para:

  • Evitar regresiones en funcionalidades criticas
  • Validar integraciones INFONAVIT
  • Asegurar calculos de estimaciones correctos
  • Garantizar RLS policies funcionan

Decision

Piramide de Testing:

Tipo Coverage Objetivo Herramienta
Unit Tests 80% Jest + Testing Library
Integration Tests 70% Jest + Supertest
E2E Tests 60% (flujos criticos) Playwright

Flujos criticos E2E:

  • Login y autenticacion
  • Crear proyecto y asignar lotes
  • Crear y aprobar estimacion
  • Proceso completo INFONAVIT
  • Portal derechohabiente

Justificacion

Leccion de Gamilit

  • 14% coverage es INACEPTABLE (muchos bugs)
  • Minimo 70% para refactoring seguro

Especifico para Construccion

  • Calculos de estimaciones deben ser exactos
  • RLS policies criticas (seguridad INFONAVIT)
  • Integraciones externas requieren mocks

Consecuencias

Positivas

  • Reduccion 70% bugs
  • Refactoring seguro
  • Deployment con confianza
  • Documentacion viva (tests como specs)

Negativas

  • Tiempo adicional de desarrollo (~20%)
  • Mitigacion: TDD reduce tiempo total

Implementacion

Acciones Requeridas

  • Configurar Jest + Testing Library
  • Configurar Playwright para E2E
  • Crear fixtures para datos de prueba
  • Implementar tests para calculos de estimaciones
  • Tests de RLS policies

Criterios de Aceptacion

  • Coverage >= 70% antes de PR
  • E2E pasan en CI/CD
  • Zero bugs criticos en calculos

Referencias