Páginas generadas
714
Páginas estáticas generadas después de añadir especialidades, herramientas y rutas localizadas.
Prueba de ingeniería
Bz Info no es solo un portfolio: es un sistema de producto verificable.
Esta página muestra la lógica técnica detrás de la plataforma: arquitectura web, backend NestJS, calidad, pruebas, operaciones, SEO, i18n y disciplina de entrega.
Husky pre-pushESLint + Prettierportfolio-api/test9 quality phasesmodule runners.reports output
Idiomas activos
6
Francés, inglés, árabe, español, alemán y neerlandés con rutas dedicadas.
Cadena de calidad
Typecheck + Build
Validación frontend sistemática antes de congelar los cambios.
Backend quality is module-owned.
Each serious module can expose its own perf, contract, unit, integration, E2E, smoke, security and mutation phases.
Mapa del sistema
Una plataforma diseñada como un producto completo.
La prueba no viene de una sola página. Viene del conjunto: sitio público, API, admin, documentación, herramientas, contenido localizado y calidad.
01 · Visible
Public web
Next.js, localized routes, SEO, sitemap, expertise pages and documentation.
02 · Architecture
Backend API
NestJS API for contact, chatbot, analytics, communication and product workflows.
03 · Operations
Admin system
Future supervision for requests, conversations, logs, statistics and operations.
04 · Expansion
Tools lab
Developer packs, scripts, transactional SMS gateway and local AI workstation.
Prueba backend
El backend se trata como la columna vertebral del producto.
El objetivo es mostrar capacidad para estructurar módulos, contratos, validaciones, flujos de dominio, seguridad e integraciones.
NestJS
Modular architecture
Modules, services, DTOs, guards, validation and maintainable API contracts.
Prisma
Controlled persistence
Models, transactions, constraints and clear separation between domain and storage.
Realtime
Live flows
Chat, support, notifications and admin interfaces connected to real system state.
Communication
Email, SMS and notifications
Transactional channels designed with limits, logs, security and precise usage.
01
HTTP request
Controller receives a public operation through a documented route.
02
DTO validation
class-validator, Swagger metadata and ValidationPipe must stay aligned.
03
Guard / auth
Access rules, JWT context, throttling and role checks protect the boundary.
04
Service decision
Business rules are isolated, testable and protected by explicit branches.
05
Prisma / storage
Transactions, constraints and persistence shape are verified by tests.
06
Reports
Schemathesis, smoke, ZAP, k6 and Stryker expose behavior from outside.
Metodología backend
Un método progresivo válido en varios frameworks.
NestJS, Spring Boot, Python, Go o .NET: el principio sigue igual. Comprender, bloquear, mejorar, medir, endurecer y documentar.
01
Reconocimiento
Leer rutas, DTOs, guards, servicios, base de datos, errores y contratos públicos.
Comprender el sistema antes de modificarlo.
02
Refactor ligero
Aclarar responsabilidades sin reescribir el producto ni romper el comportamiento existente.
Reducir deuda sin crear una migración riesgosa.
03
Pruebas base
Bloquear comportamientos existentes con pruebas simples pero útiles.
Crear una red de seguridad antes de correcciones profundas.
04
Pruebas profundas
Probar ramas, errores, límites, transacciones, null, undefined y excepciones.
Atacar ángulos muertos que las pruebas superficiales ignoran.
05
Integration & E2E
Validar fronteras reales entre API, autenticación, base de datos y servicios.
Probar el comportamiento fuera del aislamiento.
06
Performance
Medir latencia, concurrencia, contención DB, N+1, throttling, memoria y rutas lentas.
Encontrar lo que falla cuando el backend recibe carga real.
07
Contract testing
Usar OpenAPI y Schemathesis para enfrentar el contrato público al comportamiento real.
Corregir DTOs, Swagger, ValidationPipe y respuestas documentadas.
08
Runtime security
Añadir smoke checks, ZAP, logs y verificación runtime.
Observar el sistema como realmente se ejecuta.
09
Mutation testing
Usar Stryker para verificar que las pruebas detectan cambios de comportamiento.
Medir la fuerza de las pruebas, no solo la cobertura.
10
Documentación
Guardar comandos, reportes, runners y decisiones de forma reutilizable.
Hacer la calidad transferible al equipo y futuros proyectos.
Definición de pruebas
Cada tipo de prueba cubre un riesgo distinto.
La calidad backend no es una pila de carpetas. Cada fase responde a una pregunta precisa: corrección, integración, contrato, robustez, seguridad y resistencia al cambio.
00-static-quality
Static quality gate
Verifica tipado, ESLint, Prettier, build y hooks Git antes de confiar en el runtime.
When
Antes de suites pesadas, antes de commit, antes de push y antes de investigar errores profundos.
Why
Husky, ESLint y Prettier evitan que entre ruido al repositorio: formato roto, deuda de estilo, errores estáticos o build inválido.
01-perf
Performance
Mide latencia, tasa de error, concurrencia y límites visibles bajo carga.
When
Antes de validar un módulo expuesto o después de un refactor sensible.
Why
Un backend puede pasar tests unitarios y fallar bajo concurrencia real.
02-schemathesis
Schemathesis / OpenAPI
Ataca endpoints automáticamente desde el contrato OpenAPI publicado.
When
Después de estabilizar DTOs, Swagger, ValidationPipe y estados HTTP.
Why
Revela diferencias entre documentación, validación real y respuestas.
03-unit
Unit tests
Aísla decisiones, DTOs, servicios, guards o mappers para verificar ramas.
When
Al inicio del hardening, antes de refactors y para matar mutantes.
Why
Bloquea reglas importantes sin depender de red, base de datos o módulo completo.
04-integration
Integration tests
Verifica fronteras entre módulos, providers, transacciones, base y servicios.
When
Cuando la lógica depende de Prisma, repositorios o composición de servicios.
Why
Detecta errores que los mocks optimistas pueden ocultar.
05-e2e
E2E tests
Prueba un flujo API completo desde HTTP hasta comportamiento esperado.
When
Para flujos críticos como auth, contacto, admin, soporte o notificaciones.
Why
Prueba que controller, validación, auth, servicio y respuesta trabajan juntos.
06-smoke
Smoke tests
Comprueba rápidamente que el sistema vivo responde en rutas críticas.
When
Después de build, despliegue local o cambio de entorno.
Why
Evita lanzar suites caras contra una API caída o mal configurada.
07-zap
ZAP security checks
Observa la superficie HTTP expuesta para señales básicas de seguridad.
When
En rutas públicas, admin, auth o cualquier endpoint expuesto.
Why
Añade una visión runtime de la superficie atacable.
08-mutation
Stryker mutation
Cambia el código para verificar si los tests detectan cambios de comportamiento.
When
Después de una cobertura sólida, para medir la fuerza real de los tests.
Why
La cobertura no basta; Stryker mide si las assertions protegen de verdad.
portfolio-api/test
Module-by-module quality factory
Each backend module owns the same quality surface, from contract checks to mutation testing, with a dedicated global runner and local README.
01
01-perf
Load, latency and concurrency baseline.
02
02-schemathesis
OpenAPI contract attack against real endpoints.
03
03-unit
DTOs, services, guards, modules and branch decisions.
04
04-integration
Database, providers and cross-service boundaries.
05
05-e2e
Real API flows through the application surface.
06
06-smoke
Runtime availability and critical path sanity checks.
07
07-zap
Basic exposed security signals.
08
08-mutation
Stryker mutation strength and test robustness.
Sample modules already shaped with this convention
admin-authadmin-dashboardadmin-supportaudit-logschatchatbotcontacthealthleadsmonitoringnotifications
test/<module>/
├── 01-perf
├── 02-schemathesis
├── 03-unit
├── 04-integration
├── 05-e2e
├── 06-smoke
├── 07-zap
├── 08-mutation
├── scripts/run-<module>-global.sh
└── README.mdbash
Global module runner
One command can run the module quality chain with explicit toggles.
MODULE_NAME="admin-auth"RUN_ADMIN_AUTH_SCHEMATHESIS="${RUN_ADMIN_AUTH_SCHEMATHESIS:-true}"RUN_ADMIN_AUTH_SMOKE="${RUN_ADMIN_AUTH_SMOKE:-true}"RUN_ADMIN_AUTH_UNIT="${RUN_ADMIN_AUTH_UNIT:-true}"RUN_ADMIN_AUTH_INTEGRATION="${RUN_ADMIN_AUTH_INTEGRATION:-true}"RUN_ADMIN_AUTH_E2E="${RUN_ADMIN_AUTH_E2E:-true}"RUN_ADMIN_AUTH_MUTATION="${RUN_ADMIN_AUTH_MUTATION:-true}"bash
Schemathesis contract attack
OpenAPI is fetched from the running API, then attacked in Docker.
SCHEMA_FETCH_URL="${SCHEMA_FETCH_URL:-http://localhost:4002/api/docs-json}"SCHEMATHESIS_BASE_URL="${SCHEMATHESIS_BASE_URL:-http://host.docker.internal:4002}"SCHEMATHESIS_PATH_REGEX="${SCHEMATHESIS_PATH_REGEX:-^/api/v1/admin/auth/(login|refresh|logout|me)$}"docker run --rm --add-host=host.docker.internal:host-gateway \ ghcr.io/schemathesis/schemathesis:stable run openapi-admin-auth.jsonjson
Stryker mutation gate
Mutation score is a hard quality threshold, not a vanity metric.
{ "testRunner": "jest", "mutate": ["src/modules/admin-auth/**/*.ts"], "coverageAnalysis": "perTest", "thresholds": { "high": 100, "low": 100, "break": 100 }}javascript
k6 health baseline
Performance tests expose latency and failure-rate risks outside unit isolation.
export const options = { thresholds: { http_req_failed: ["rate<0.01"], checks: ["rate>0.99"], "http_req_duration{endpoint:health}": ["p(95)<250", "p(99)<500"], },};Herramienta → riesgo
Cada herramienta ataca una categoría distinta de riesgo.
La calidad no es una lista de logos. Cada etapa tiene una razón precisa y cubre un ángulo diferente.
TypeScript
Errores estáticos
Detecta incoherencias antes del runtime, especialmente en DTOs, servicios y contratos internos.
Unit tests
Reglas frágiles
Bloquean reglas importantes, ramas, errores y casos límite aislados.
Integration tests
Fronteras invisibles
Verifican interacciones entre servicios, transacciones, base de datos y dependencias.
E2E tests
Flujos API incompletos
Validan flujos reales desde el endpoint hasta el comportamiento esperado.
k6
Carga y concurrencia
Expone latencia, locks, N+1, contención y comportamientos que no aparecen aislados.
Schemathesis
Contrato OpenAPI falso
Revela diferencias entre Swagger, DTOs, ValidationPipe, estados HTTP y respuestas reales.
ZAP
Superficie runtime
Detecta señales básicas de seguridad visibles desde fuera.
Stryker
Pruebas débiles
Prueba si la suite detecta mutaciones de comportamiento.
Modelo de confianza
La confianza sube cuando se atacan varios riesgos.
Este gráfico es un modelo pedagógico, no una estadística científica.
Static
20%El código compila y se reducen errores evidentes.
Unit
38%Las decisiones principales empiezan a estar bloqueadas.
Integration
55%Las fronteras servicio/base/API son más seguras.
E2E
68%Los flujos reales se validan de extremo a extremo.
Contract
80%El contrato público se ataca automáticamente.
Runtime
88%Performance, smoke y seguridad runtime añaden visión real.
Mutation
95%La suite demuestra que detecta cambios peligrosos.
Pipeline de calidad
La calidad es una cadena, no decoración.
Cada etapa reduce una categoría de riesgo: tipado, contrato, comportamiento, runtime, seguridad o robustez de pruebas.
01
Static confidence
Check typing, formatting, conventions and obvious errors before runtime.
TypeScriptESLintPrettierBuild
02
Behavior confidence
Test business decisions, integrations and end-to-end user paths.
UnitIntegrationE2ESmoke
03
Contract confidence
Attack API contracts and verify that documentation reflects real behavior.
OpenAPISchemathesisSwaggerDTO validation
04
Hardening confidence
Actively look for weaknesses instead of stopping at a green build.
StrykerZAPk6Audit logs
Lo que demuestra
El valor está en la disciplina repetida.
La página muestra un método: estructurar, verificar, documentar, localizar, medir y refactorizar cuando aparece un límite.
Readable architecture
Pages, content, components and routes are separated to stay maintainable.
Real refactoring
Oversized files are split instead of being accepted as silent debt.
Verifiable SEO
Sitemap, canonical, hreflang and localized routes are treated as public contracts.
Proof through product
The site itself demonstrates the expected level: content, UI, architecture and validation.
Prueba utilizable
Una conversación técnica puede partir de pruebas concretas.
Para una misión backend, recuperación técnica o plataforma producto, esta página sirve como entrada técnica.