Uma gerente de testes de software propôs a seu time de dese...

Vamos analisar a questão proposta e entender a abordagem Test Driven Development (TDD), que é uma prática fundamental no desenvolvimento de software moderno.

Alternativa Correta: A - antes de implementar alguma funcionalidade em si.

TDD é uma metodologia de desenvolvimento de software onde os testes são escritos antes da implementação do código. A ideia central é que você deve primeiro definir como a funcionalidade deve se comportar (através de testes automatizados) e só então escrever o código para atender a esses testes. Isso proporciona diversos benefícios, tais como código mais limpo e melhor cobertura de testes.

Agora, vamos justificar cada alternativa para entender por que a alternativa “A” é a correta e as outras estão incorretas:

Alternativa A: “antes de implementar alguma funcionalidade em si.”

Essa é a essência do TDD. Você escreve um teste que define uma melhoria ou uma nova função, faz com que o teste falhe (porque a funcionalidade ainda não foi implementada), e então escreve o código para passar no teste. Por isso, inicia-se o desenvolvimento de testes antes de implementar qualquer funcionalidade.

Alternativa B: “durante o período de homologação.”

Essa alternativa está incorreta porque a homologação é uma etapa posterior no ciclo de desenvolvimento, geralmente destinada a testes de aceitação e validação do sistema. No TDD, o desenvolvimento de testes acontece bem antes, durante a fase inicial de desenvolvimento.

Alternativa C: “após as funcionalidades serem construídas.”

Isso descreve a abordagem tradicional, onde os testes são escritos depois do código. No entanto, essa prática é contrária ao TDD, que preconiza a escrita de testes antes da implementação do código.

Alternativa D: “quando a primeira leva de funcionalidades planejadas forem codificadas em algum sprint.”

Essa alternativa sugere que os testes são escritos após uma fase inicial de desenvolvimento. No TDD, os testes devem ser escritos antes de qualquer codificação de funcionalidades, e não após um sprint inicial.

Alternativa E: “pelos testes de interface automatizado, seguidos pelos testes unitários.”

Embora os testes automatizados e unitários sejam importantes, essa alternativa não se alinha com a abordagem TDD. No TDD, você começa com testes unitários, e não com testes de interface automatizados.

Espero que esta explicação tenha esclarecido a essência do TDD e a razão pela qual a alternativa A é a correta. Se tiver mais dúvidas, sinta-se à vontade para perguntar!

Letra - A

No TDD basicamente são criados testes antes do código de cada funcionalidade. Isso funciona em ciclos, onde inicialmente é escrito o teste e o executado com o objetivo de que ele falhe. Após isso, é criado o código da funcionalidade e rodado novamente o teste, que por sua vez irá passar.

Há três ciclos:

• Red: escreva um pequeno teste automatizado que, ao ser executado, irá falhar;
• Green: implemente um código que seja suficiente para ser aprovado no teste recém-escrito;
• Refactor: refatore o código, a fim dele ser melhorado, deixando-o mais funcional e mais limpo.

Para realizar o teste em cada funcionalidade do seu código, irá sempre seguir estes ciclos. Estes ciclos são comumente referenciados como red-green-refactor ou red-green-blue.

TDD- Desenvolvimento orientado a testes-.é uma abordagem de desenvolvimento de software que enfatiza a escrita de testes antes da implementação do código.

TDD - É baseado na ideia de desenvolver o teste para o código antes mesmo de codificar a funcionalidade.