Dando continuidade ao desafio proposto no módulo de Concorrência e Paralelismo (Acelerando o Job de Auditoria). Ainda em um ambiente hipotético:

O código do "Job de Auditoria de Alta Performance" foi aprovado no code review e "mergeado" para a main. A gerência está satisfeita com a performance.

No entanto, um novo engenheiro júnior tentou fazer uma "pequena otimização" no ProcessPipeline e reintroduziu uma race condition sutil que corrompeu os relatórios por um dia inteiro. O bug não foi pego porque não havia uma suíte de testes automatizada.

Sua missão é garantir que isso nunca mais aconteça. Você deve construir uma suíte de testes robusta que valide a corretude, a segurança de concorrência e a performance do nosso processador de logs.

🎯 Objetivos

Este desafio é sobre criar uma rede de segurança. Ao final, você deve ter provado que domina:

1. Testes Unitários: Isolar e testar as menores unidades de lógica.
2. Testes de Tabela (Table-Driven Tests): Escrever testes limpos, eficazes e fáceis de manter para lógica complexa, cobrindo múltiplos cenários de sucesso e falha.

💻 Suas Tarefas

Crie um arquivo main_test.go no mesmo pacote. Você usará o pacote testing nativo do Go.

🎯 Parte 1: Testes Unitários (A Base)

Alvo: A lógica interna do Report.

1. TestReportAddition: Escreva um teste de unidade para os métodos AddEvent e AddError.
   • Crie um NewReport().
   • Adicione alguns eventos e erros.
   • Verifique se os contadores (TotalEvents, TotalErrors) e os mapas (EventsByType, EventsByRegion) contêm os valores exatos esperados.
   • Use t.Errorf() ou t.Fatalf() se o resultado estiver incorreto.
2. TestReportConcurrency (O Teste de Estresse):
   • Escreva um teste que prove que AddEventSafe e AddErrorSafe são, de fato, thread-safe.
   • Crie um NewReport().
   • Use um sync.WaitGroup e dispare 1000 goroutines simultaneamente.
   • Cada goroutine deve chamar report.AddEventSafe(event) e report.AddErrorSafe() algumas vezes.

🎯 Parte 2: Testes de Tabela (Validando a Lógica)

Alvo: A lógica de parsing e processamento de linhas.

1. TestProcessLine: (Se você tiver uma função parseLine ou similar) ou TestProcessFileHelper (testando o processFile).
2. Crie uma estrutura (struct) para a sua tabela de teste.
3. Use t.Run() para iterar sobre a tabela e criar um sub-teste para cada caso. Isso torna os relatórios de falha muito mais claros.

Resultados Esperados

1. Cobertura: A suíte de testes deve cobrir a lógica de agregação, a lógica de parsing e os fluxos completos.