Questão 795169

• Banca: FCC
• Órgão: TST
• Ano: 2012
• Provas: FCC - 2012 - TST - Técnico Judiciário - Programação
• Disciplina: Engenharia de Software
• Assuntos: Teste de Software

O processo de desenvolvimento orientado a testes, de uma forma geral, é baseado em 3 passos. Estes 3 passos são repetidos até que não se consiga pensar em novos testes, o que indicaria, então, que a funcionalidade está pronta. Um destes passos e o que nele deve ser feito está expresso corretamente em:

• A. Refatore é o passo 3. Uma vez que o teste tenha passado, deve-se verificar o que pode ser melhorado no código e remover as duplicações. Essas melhorias no código, no entanto, devem permitir que os testes continuem passando.
  
• B. Escreva um teste que falhe é o passo 2. Neste passo definem-se quais são as verificações que precisam ser feitas. Deve-se pensar primeiro no teste e só depois que este estiver pronto cria-se o código necessário para que ele compile e falhe ao ser executado.
  
• C. Faça o teste passar é o passo 1. Neste passo escreve-se apenas código suficiente para que o teste passe. Mesmo que se saiba que o código deve fazer mais coisas, fazer os testes passarem deve ser a única preocupação nesta etapa.
  
• D. Keep it simple é o passo 1. Como a solução vai surgindo pouco a pouco, a tendência é que não se perca tempo com aquilo que não se tem certeza que será usado em seguida, então, o foco deve estar no planejamento de testes simples.
  
• E. Documente o teste é o passo 3. Os testes, quando bem definidos, são mais simples de ler que o código e, embora nem sempre sirvam como uma especificação para o usuário final, eles são uma fonte eficiente para entender o que o software faz. Além disso, esta documentação sempre estará atualizada com a aplicação.
  

Gabarito: A

Comentários

• Teste-Codificação-Refatoração.

• O processo de criação de programação orientado a testes é simples:

  Escreva um teste que falhe. Pense no que o código deve fazer, descreva o contexto e defina quais são as verificações que precisam ser feitas. Não há um limite no número de testes, então quanto menos coisa cada teste descrever/verificar, melhor. No início também não é preciso se preocupar se a classe/método ainda não existe. Pense primeiro no teste e só depois que este estiver pronto crie o esqueleto de código necessário para que ele compile e falhe ao rodar.

  Faça o teste passar. Agora chegou o ponto crucial: escreva o mínimo de código para que o teste passe. Controle o instinto natural do programador de tentar prever tudo que o código vai fazer e apenas faça o teste passar. Mesmo que tenha certeza que o código deve fazer mais coisas, fazer os testes passarem deve ser a única preocupação agora.

  Refatore. Uma vez que o teste passou, verifique o que no código pode ser melhorado. Geralmente para um teste passar é preciso inserir duplicação através de constantes (técnica conhecida comoFake It). Agora é a hora de melhorar o código e remover as duplicações, lembrando que os testes devem continuar passando.

• a. Correta.
  b. Esse é o passo 1.
  
  

  c. Esse é o passo 2.

• Sobre a letra d) Keep it simple: é um padrão de projeto, acrônimo KISS (Keep It Simple Stupid) rsrsrs

  Sobre a letra e) A documentação dos testes está implícita no TDD.

• Lema do TDD: Red (testes falhando), Green (testes passando), Refactor

• Engraçado, o sommerville não seguiu o Keep it Simple Stupid e resolveu inventar que TDD tem 5 passos e não 3.