Desenvolvimento guiado por testes (TDD) é uma técnica de desenvolvimento de software que
- A)incentiva a construção de um alto número de testes de unidades de modo a eliminar a necessidade dos testes de integração e aceitação.
Errada, porque TDD não elimina a necessidade de testes de integração e aceitação; ele foca principalmente em testes unitários antes do código.
- B)requer que os desenvolvedores escrevam testes de unidades antes da codificação da aplicação.
Certa, porque o TDD exige que os testes de unidade sejam escritos antes da implementação da aplicação.
- C)delimita o tempo máximo que o programador deve empenhar escrevendo testes para manter a produtividade.
Errada, porque TDD não define limite de tempo para escrever testes, e sim uma ordem de desenvolvimento baseada em testes.
- D)testa unidades de ativos efêmeros que devem ser invalidados após o uso, pois repetir testes é um desperdício de tempo.
Errada, porque TDD não trata de ativos efêmeros nem de invalidar testes após o uso; testes devem ser repetíveis.
- E)encoraja os desenvolvedores a escreverem testes apenas para verificação dos bugs detectados pelo usuário final na etapa de aceitação.
Errada, porque TDD não se limita a corrigir bugs encontrados no fim; ele antecipa a validação com testes escritos antes do código.
Gabarito: B
O TDD, ou desenvolvimento guiado por testes, inverte a ordem tradicional: primeiro você pensa no comportamento esperado em forma de teste, depois escreve o código para fazer o teste passar. A ideia é simples e poderosa: os testes funcionam como uma espécie de roteiro do que o software deve fazer, reduzindo retrabalho e ajudando a manter o código mais enxuto e confiável. Na prática, o ciclo clássico do TDD é conhecido como red-green-refactor: você escreve um teste que inicialmente falha, implementa o mínimo necessário para ele passar e, depois, refatora o código com segurança. Isso ajuda muito em testes unitários, porque você valida pequenas partes do sistema com feedback rápido. Por isso, o gabarito é a letra B. O enunciado descreve exatamente o ponto central do TDD: escrever testes de unidade antes da codificação da aplicação. Não é sobre eliminar outros tipos de teste, nem sobre impor limite de tempo, nem sobre testar algo que seja descartado depois. É sobre orientar o desenvolvimento a partir dos testes. Em termos doutrinários, essa é a essência mais cobrada em concursos: TDD não substitui integração e aceitação, apenas organiza o desenvolvimento a partir de testes unitários antecipados. Se a questão falar em "antes do código", "primeiro o teste" ou "red-green-refactor", acenda a luzinha do TDD.