Questão de Engenharia de Software — Geral — FCC 2025

Teste de Software: Estratégia de Testes para Regras de Negócio Críticas

Gabarito: letra A. A alternativa correta combina testes unitários (JUnit), testes de integração (Mockito) e testes funcionais automatizados, todos alinhados aos requisitos legais — exatamente o que a boa prática de engenharia de software recomenda para um módulo de cálculo de horas extras e banco de horas, onde a precisão jurídica é crítica. As demais alternativas erram ao descartar a automação, ignorar a integração, ou priorizar métricas isoladas em detrimento dos requisitos.

O cenário descreve um módulo com regras de negócio complexas e alto impacto jurídico. Nesse contexto, a estratégia de testes não pode ser improvisada: ela precisa ser sistemática, automatizada e rastreável aos requisitos. A alternativa A captura essa essência ao propor uma pirâmide de testes — uma combinação de níveis que se complementam. Os testes unitários (JUnit) verificam a menor unidade de código (métodos de cálculo), os testes de integração (Mockito) validam a interação entre componentes simulando dependências externas, e os testes funcionais confirmam que o sistema atende aos requisitos de negócio. Essa abordagem é defendida por autores como Sommerville e Pressman, que destacam a importância de testar em diferentes níveis de granularidade.

A pegadinha central desta questão é a tentação de escolher uma alternativa que pareça "prática" (como a B, que valoriza a intuição) ou "simples" (como a D, que foca só em testes unitários). Mas em um sistema com regras jurídicas, a documentação formal dos requisitos e critérios de aceitação é indispensável — ela é a base para validar se o software está correto. A alternativa A reconhece isso ao mencionar a validação com base nos "requisitos legais definidos pela área jurídica".

Outro ponto crucial é a distinção entre verificação e validação. A verificação pergunta "estamos construindo o produto certo?" (conformidade com a especificação), enquanto a validação pergunta "construímos o produto certo?" (atende às necessidades do usuário). No contexto da questão, os testes funcionais automatizados, validados com base nos requisitos legais, cumprem o papel de validação — garantem que o sistema realmente atende às normas do CNJ e da CLT sobre jornada de trabalho.

A alternativa A também acerta ao usar Mockito nos testes de integração. Mockito é um framework de mocking que permite simular dependências (como APIs de ponto eletrônico e folha de pagamento), isolando o comportamento do módulo em teste. Isso é essencial para testar a integração sem depender de sistemas externos, que podem não estar disponíveis ou ser instáveis durante o desenvolvimento.

Por fim, a alternativa A é a única que oferece uma estratégia completa e equilibrada, cobrindo todos os níveis de teste e alinhando-os aos requisitos de negócio. As demais alternativas, cada uma à sua maneira, apresentam uma lacuna grave: ou ignoram a automação, ou negligenciam a integração, ou substituem a qualidade por uma métrica isolada. Guarde esse critério: uma boa estratégia de testes para regras críticas deve ser automatizada, em múltiplos níveis e rastreável aos requisitos — é exatamente isso que separa a alternativa A das demais.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta alternativa descreve a estratégia de testes ideal para o cenário. Ela combina:

• Testes unitários com JUnit: verificam os métodos de cálculo de horas extras e banco de horas isoladamente, garantindo a corretude da lógica em sua menor unidade.

• Testes de integração com Mockito: simulam dependências (APIs de ponto eletrônico, folha de pagamento) para validar a interação entre o módulo e seus componentes externos, sem depender de sistemas reais.

• Testes funcionais automatizados: validam o sistema como um todo, confirmando que os requisitos legais (normas do CNJ, CLT) foram implementados corretamente.

Essa abordagem é sistemática, automatizada e rastreável aos requisitos, exatamente o que a boa engenharia de software recomenda para regras de negócio críticas. A menção à "validação com base nos requisitos legais" é o diferencial: garante que os testes não são apenas técnicos, mas também juridicamente precisos.

Alternativa B — ❌ Incorreta

A alternativa B defende testes exploratórios baseados na intuição e descarta a documentação formal. Isso é um erro grave em um contexto de regras jurídicas complexas. A intuição dos desenvolvedores é valiosa, mas não substitui a documentação de requisitos e critérios de aceitação — especialmente quando a precisão legal é crítica. Sem documentação, não há como rastrear se o sistema atende às normas do CNJ, nem como validar mudanças futuras. A experiência prática é um complemento, não um substituto.

Alternativa C — ❌ Incorreta

A alternativa C prioriza testes manuais e evita ferramentas como JUnit, alegando que testes automatizados são "frágeis para cálculos complexos". Isso é um mito: testes automatizados são especialmente adequados para cálculos complexos, pois permitem executar milhares de cenários rapidamente e com precisão, sem erro humano. Testes manuais são importantes, mas não devem ser a única estratégia — eles são lentos, propensos a erros e difíceis de repetir. A automação é essencial para garantir estabilidade e facilitar futuras alterações, como o enunciado menciona.

Alternativa D — ❌ Incorreta

A alternativa D foca apenas em testes unitários e dispensa a verificação das integrações. Isso é uma lacuna grave: mesmo que os métodos de cálculo estejam corretos isoladamente, a integração com APIs de ponto eletrônico e folha de pagamento pode falhar. Testes de integração são essenciais para validar a comunicação entre componentes e garantir que os dados fluem corretamente. Ignorar essa camada é um risco enorme em um sistema que depende de dados externos para calcular horas extras.

Alternativa E — ❌ Incorreta

A alternativa E usa cobertura de código (code coverage) como único critério de qualidade, exigindo 90% de cobertura. Embora a cobertura seja uma métrica útil, ela não garante a qualidade — um código pode ter 100% de cobertura e ainda conter bugs, se os testes não verificarem os comportamentos corretos. Além disso, a alternativa ignora os requisitos críticos das normas do CNJ, que são o coração do sistema. A cobertura deve ser um complemento, não um substituto, para uma estratégia de testes baseada em requisitos.

Gabarito: letra A