O CrashLab é uma iniciativa educacional voltada para desenvolvedores em início de carreira, com o objetivo de simular cenários reais de manutenção de software em ambientes corporativos.
O Challenge 1 — Intermittent Failure introduz um problema clássico de produção:
Um sistema aparentemente estável apresenta falhas ocasionais sob condições específicas, exigindo investigação técnica baseada em evidências.
Diferente de exercícios acadêmicos, este desafio foi projetado para reproduzir características reais de sistemas legados, incluindo inconsistências de validação, baixa observabilidade e bugs não triviais.
Capacitar o participante a:
- Diagnosticar falhas intermitentes
- Reproduzir erros a partir de cenários específicos
- Identificar causa raiz em código não ideal
- Corrigir o problema de forma segura
- Garantir ausência de regressão por meio de testes
O desafio foca exclusivamente em:
- Análise de fluxo de execução
- Investigação estruturada
- Uso de testes como ferramenta de diagnóstico
- Diferenciação entre sintoma e causa raiz
Para garantir foco e efetividade pedagógica, o desafio intencionalmente exclui:
- Arquitetura distribuída
- Mensageria (ex: filas)
- Processamento assíncrono
- Banco de dados
- Refatorações estruturais extensas
O objetivo é isolar a habilidade de debugging sem interferência de complexidade infraestrutural.
O desafio utiliza uma stack moderna, porém simplificada:
- .NET 10
- ASP.NET Core (Minimal API)
- xUnit (testes automatizados)
- Swagger (exploração da API)
- ILogger (logging básico)
A aplicação segue uma separação leve de responsabilidades, inspirada em sistemas reais:
/src
CrashLab.Api → entrada HTTP (Minimal API)
CrashLab.Application → lógica de negócio (onde o bug reside)
CrashLab.Domain → entidades
/tests
CrashLab.TestsHTTP Request
→ Endpoint Minimal API
→ DocumentProcessor
→ Normalize()
→ Validate()
→ Process()
A aplicação recebe um documento via requisição HTTP e realiza processamento síncrono.
POST /documents/process
- Documentos válidos devem ser processados com sucesso
- Em cenários específicos, ocorre falha em tempo de execução
- O erro não é evidente e depende de condições específicas do input
- NullReferenceException
- Dependente de contexto (não ocorre sempre)
- Distribuído ao longo do fluxo
- Não está localizado em um único ponto
- Não é detectado pelos testes existentes
- Depende de combinação de dados (ex: tipo do documento)
{
"type": "invoice",
"customer": {
"name": "Gabrielly"
}
}O erro ocorre apenas quando:
type = "invoice"customer.addressestá ausente
O desafio incorpora elementos comuns em sistemas reais:
- Validações incompletas
- Suposições implícitas no código
- Uso de strings ao invés de tipos fortes
- Logging insuficiente
- Inconsistência entre contrato e implementação
[ERROR] Failed processing document type=invoice
Informação insuficiente para diagnóstico direto.
- Existem testes automatizados ✔️
- Todos passam ✔️
- Cobertura incompleta ❌
Os testes cobrem apenas o cenário ideal (happy path), não contemplando variações reais de dados.
O participante deverá:
- Utilizando Swagger ou testes
- Representando o cenário problemático
- Através da análise do fluxo e código
- Sem alterar comportamentos válidos
- Todos os testes devem passar
A avaliação será conduzida via Code Review, simulando ambiente profissional.
- Reprodução correta do erro
- Qualidade do teste criado
- Identificação precisa da causa raiz
- Correção adequada e segura
- Preservação do comportamento existente
- Clareza da solução
- Coerência na tomada de decisão
- Evitação de “quick fixes”
- Entendimento do fluxo completo
O participante deve submeter:
- Código com correção implementada
- Teste automatizado cobrindo o cenário
- Explicação da causa raiz (README ou comentário técnico)
Este desafio se destaca por:
- Simular condições reais de sistemas legados
- Focar em uma habilidade crítica e pouco treinada
- Utilizar code review como mecanismo de avaliação
- Evitar complexidade artificial (infraestrutura)
| Dimensão | Nível |
|---|---|
| Infraestrutura | Baixo |
| Implementação | Médio |
| Raciocínio | Alto |
Ao final do desafio, o participante deverá demonstrar:
- Capacidade de investigação técnica estruturada
- Uso eficaz de testes para diagnóstico
- Entendimento de causa raiz
- Correção segura em código legado
Este é o primeiro desafio do CrashLab, com foco em:
Fundamentos de debugging antes da introdução de complexidade arquitetural
Desafios posteriores poderão incluir:
- Concorrência
- Processamento assíncrono
- Integrações externas
- Arquiteturas distribuídas
O Challenge 1 — Intermittent Failure estabelece a base do programa CrashLab ao desenvolver uma competência essencial para atuação profissional:
A capacidade de investigar, compreender e corrigir problemas reais em sistemas imperfeitos.
A proposta equilibra realismo e controle, oferecendo um ambiente seguro para desenvolvimento de habilidades críticas amplamente exigidas no mercado