TDD é uma das práticas de programação propostas dentro do escopo das metodologias ágeis. Com relação aos objetivos propostos pelo TDD, analise os itens a seguir. I. Favorecer a escrita de códigos com alta testabilidade. Essa característica é uma consequência natural da manutenção do fluxo de trabalho proposta pela metodologia XP. Por exemplo, como o desenvolvedor sabe que ele terá que escrever a classe C e depois o teste T, é natural que desde o início ele planeje C de forma a facilitar a escrita de T. II. Prática relacionada não apenas com testes, mas também com a melhoria do design de um sistema. Isso acontece porque o desenvolvedor, coloca-se na posição de um usuário da classe C para escrever um teste T. III. Evitar que os desenvolvedores esqueçam de escrever testes. TDD promove testes à primeira atividade de qualquer tarefa de programação, seja ela corrigir um bug ou implementar o código de uma nova funcionalidade. Está correto o que se afirma em:
- A)I, apenas.
Errada, porque a testabilidade pode ser um efeito do TDD, mas a assertiva isola isso como objetivo principal de forma imprecisa.
- B)III, apenas.
Errada, porque o TDD não serve apenas para evitar esquecimento de testes; ele também influencia diretamente o design e a forma de implementação.
- C)I e II, apenas.
Errada, porque a assertiva I não é aceita como correta pela banca, então não basta apontar apenas I.
- D)II e III, apenas.
Certa, porque TDD melhora o design do sistema e também evita que os testes fiquem para depois ou sejam esquecidos.
- E)I, II e III.
Errada, porque a assertiva I não está correta na forma como foi apresentada.
Gabarito: D
TDD, ou Test-Driven Development, é a prática de escrever o teste antes de escrever o código de produção. O ciclo clássico é bem conhecido: escreva um teste que falha, implemente o mínimo para passar e depois refatore. Parece simples, mas é justamente esse ritual que força o desenvolvedor a pensar na interface da classe, nas dependências e na forma de uso antes de sair codando no impulso. Por isso, o TDD não serve só para "fazer teste". Ele também ajuda no design do sistema, porque você pensa como quem vai usar a classe ou o componente. Quando você tenta escrever o teste primeiro, percebe rapidamente se a classe está fácil ou difícil de ser acionada. Se o teste ficou confuso, normalmente o design também está pedindo socorro. A assertiva II está correta por esse motivo: TDD melhora o design ao colocar você na posição de usuário da classe ao escrever o teste. Já a assertiva III também está correta, porque o teste deixa de ser algo que "se faz depois, se der tempo" e passa a ser parte da rotina de desenvolvimento, reduzindo o risco de esquecer de testar uma correção ou uma nova funcionalidade. Em metodologias ágeis, isso conversa muito com XP, em que testes automatizados são valorizados o tempo todo. A pegadinha da questão está na assertiva I. Embora TDD realmente acabe favorecendo código mais testável, a banca trata isso com cuidado: o ponto central do TDD não é apenas gerar testabilidade como objetivo isolado, e sim dirigir o desenvolvimento por meio dos testes e melhorar o desenho do código. Em prova da FGV, vale lembrar: TDD é muito mais do que "testar depois"; ele puxa o design junto pela gola.