Hey estimados devs, aquí continuaré dando respuesta a las preguntas planteadas en este artículo. El nivel está por las nubes, aprovéchalo.
Categoría 6: Testing, logging y Observabilidad
24. ¿Cómo implementarías pruebas unitarias y de integración en un proyecto .NET?
En un proyecto .NET, las pruebas unitarias deben centrarse en componentes aislados, evitando dependencias externas. Por ejemplo, un servicio que aplica reglas de negocio puede probarse usando xUnit y Moq para simular repositorios. Esto asegura velocidad y retroalimentación inmediata en cada commit.
Por otra parte dev, las pruebas de integración validan la interacción con dependencias reales: bases de datos, colas, APIs externas. En .NET es común usar Testcontainers para levantar un SQL Server o RabbitMQ temporal en Docker durante la ejecución de pruebas. Esto evita acoplarse a entornos compartidos y reproduce escenarios de producción de forma confiable.
En proyectos de la industria, se suelen integrar ambas en un pipeline de CI/CD: primero unitarias rápidas, luego integración con infraestructura efímera. Así se reduce el riesgo de falsos positivos y se asegura calidad desde el core hasta los bordes del sistema.
Aquí te muestro las convenciones que debes usar para tus unit tests.
25. ¿Qué buenas prácticas recomiendas para logging y observabilidad en .NET (Serilog, OpenTelemetry, Application Insights)?
En .NET, el stack recomendado combina Serilog para logging estructurado con sinks hacia Elastic, Seq o Azure Application Insights. Esto permite correlacionar eventos por requestId o traceId.
Por ejemplo, puedes configurar UseSerilog() en Program.cs y enriquecer logs con contexto (usuario, endpoint, latency).
Para observabilidad más allá del logging, OpenTelemetry es hoy estándar de facto: métricas (Prometheus, Azure Monitor), trazas distribuidas (Jaeger, Zipkin) y logs unificados. En producción, esto habilita analizar flujos completos entre microservicios.
La buena práctica es definir niveles de log (Information, Warning, Error, Fatal) y evitar hacer log de datos sensibles.
En empresas como Microsoft o Stack Overflow, el enfoque es “logs accionables”: registros que permiten identificar y resolver incidentes, no solo almacenar ruido.
Si quieres puedes echar un vistazo a estos dos artículos muy buenos de Nick Craver:
https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition
https://nickcraver.com/blog/2018/11/29/stack-overflow-how-we-do-monitoring
Donde muestra la arquitectura que usa Stack Overflow y cómo hace monitorización.
26. ¿Qué es la Testing Pyramid y cómo la aplicarías en un proyecto .NET? (Evalúa comprensión de la estrategia de testing, no solo herramientas).
La Testing Pyramid establece que la mayor proporción de pruebas deben ser unitarias (rápidas y baratas), seguidas por integración y, en menor medida, pruebas end-to-end (E2E). En un proyecto .NET esto significa:
- Unitarias (70%): validan lógica de negocio con frameworks como xUnit/MSTest y mocks.
- Integración (20–25%): prueban interacciones con EF Core, SQL Server o servicios externos usando Testcontainers o entornos controlados.
- E2E/UI (5–10%): validan escenarios completos vía Playwright o Selenium, pero se ejecutan solo en etapas clave del pipeline.
Aplicar esta pirámide evita que el equipo dependa de pruebas lentas y frágiles en UI, y en su lugar da prioridad a la velocidad y estabilidad. Empresas que operan con Continuous Deployment, como GitHub o Netflix, aplican este modelo para balancear costo y confianza en sus suites de pruebas, así que puedes mencionarlas, estimado dev, eso te dará un tremendo plus.
Pues bien, eso es todo por ahora, dev, en la siguiente entrada seguimos con la última categoría!
¡Si esta entrada te ha gustado, compártela ah! 💪🏼
Créditos de imagen de portada: Basada en Foto de Gerald Schömbs en Unsplash