A respeito do desenvolvimento orientado a testes (TDD) e aut...

Gabarito: C - Certo

O Desenvolvimento Orientado a Testes, conhecido pela sigla TDD (Test-Driven Development), é uma prática de engenharia de software que enfatiza a criação de testes antes mesmo de se escrever o código da funcionalidade propriamente dito. Este processo segue um ciclo curto e repetitivo de etapas:

1. Criar um teste falho: O desenvolvedor escreve um teste para uma nova funcionalidade que ainda não existe no código. Por isso, é esperado que esse teste falhe, pois o código correspondente à funcionalidade testada ainda não foi implementado.
2. Escrever o código: Com o teste falho criado, o próximo passo é desenvolver o código necessário para fazer o teste passar. Neste ponto, o foco é em escrever o código estritamente necessário para a passagem do teste.
3. Refatorar: Após fazer o teste passar com sucesso, o desenvolvedor refatora o código para melhorar aspectos como legibilidade, estrutura e performance, sem alterar seu comportamento externo.

Este ciclo é conhecido como Red-Green-Refactor, onde "Red" significa escrever o teste que falha (o teste falho), "Green" é fazer o teste passar desenvolvendo o código, e "Refactor" é melhorar o código sem alterar seu comportamento externo.

A questão menciona que o primeiro passo no TDD é criar um teste falho, e isso está correto. A prática é iniciar com um teste que defina o que se espera que o código faça, mesmo sabendo que inicialmente o teste não será bem-sucedido, pois o código para a nova funcionalidade ainda não foi criado. Assim, o teste serve como uma definição clara e executável dos critérios de aceitação da funcionalidade ainda a ser implementada.

Portanto, a afirmação da questão está alinhada com as práticas do TDD, e o gabarito correto é realmente C - Certo.

O mantra do TDD é red, green e refactor.

Mas porque escrever um teste que falha?

O TDD começa pelo fim, pelo objetivo do programa. Então antes de escrever o código em si, você elabora um teste para o código que você irá escrever. Esse primeiro teste falha porque ele é só o teste, de modo que ele vai chamar classes e métodos que ainda não foram escritos.

Mais ou menos assim: você está estudando para concurso e pega um assunto que nunca viu na vida, então antes de você estudar você baixa um simulado (um teste), você tenta fazer o simulado e erra, por razões óbvias, você não tinha os assuntos em mente. Ai você estuda e depois você faz o simulado de novo e vai acertar.

Red - é a criação do teste - do teste falho

Green - é a criação do código que irá passar no teste

Refactor - é a limpeza do código, uma limpeza com o cuidado de não introduzir erros.

O mantra do TDD é RED, GREEN e REFACTOR.

Mas porque escrever um teste que falha?

O TDD começa pelo fim, pelo objetivo do programa. Então antes de escrever o código em si, você elabora um teste para o código que você irá escrever. Esse primeiro teste falha porque ele é só o teste, de modo que ele vai chamar classes e métodos que ainda não foram escritos.

Mais ou menos assim: você está estudando para concurso e pega um assunto que nunca viu na vida, então antes de você estudar você baixa um simulado (um teste), você tenta fazer o simulado e erra, por razões óbvias, você não tinha os assuntos em mente. Ai você estuda e depois você faz o simulado de novo e vai acertar.

Red - é a criação do teste - do teste falho

Green - é a criação do código que irá passar no teste

Refactor - é a limpeza do código, uma limpeza com o cuidado de não introduzir erros.

O processo fundamental de TDD é mostrado na Figura 8.9. As etapas do processo são:

1. Você começa identificando o incremento de funcionalidade necessário. Este, normalmente, deve ser pequeno
e implementável em poucas linhas de código.

2. Você escreve um teste para essa funcionalidade e o implementa como um teste automatizado. Isso significa
que o teste pode ser executado e relatará se passou ou falhou.

3. Você, então, executa o teste, junto com todos os outros testes implementados. Inicialmente, você não terá im­
plementado a funcionalidade, logo, o novo teste falhará. Isso é proposital, pois mostra que o teste acrescenta
algo ao conjunto de testes.

4. Você, então, implementa a funcionalidade e executa novamente o teste. Isso pode envolver a refatoração do
código existente para melhorá-lo e adicionar um novo código sobre o que já está lá.

5. Depois que todos os testes forem executados com sucesso, você caminha para implementar a próxima parte
da funcionalidade.

fail -> pass -> refactor

c-

“Test-driven development” refers to a style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing unit tests) and design (in the form of refactoring).

The following sequence is based on the book Test-Driven Development by Example:

1. Add a test

   The adding of a new feature begins by writing a test that passes iff the feature's specifications are met. The developer can discover these specifications by asking about use cases and user stories. A key benefit of test-driven development is that it makes the developer focus on requirements before writing code. This is in contrast with the usual practice, where unit tests are only written after code.

2. Run all tests. The new test should fail for expected reasons

   This shows that new code is actually needed for the desired feature. It validates that the test harness is working correctly. It rules out the possibility that the new test is flawed and will always pass.

3. Write the simplest code that passes the new test

   Inelegant or hard code is acceptable, as long as it passes the test. The code will be honed anyway in Step 5. No code should be added beyond the tested functionality.

4. All tests should now pass

   If any fail, the new code must be revised until they pass. This ensures the new code meets the test requirements and does not break existing features.

5. Refactor as needed, using tests after each refactor to ensure that functionality is preserved

https://en.wikipedia.org/wiki/Test-driven_development