O que é Desenvolvimento Orientado a Testes (TDD)? Exemplo

O que é Desenvolvimento Orientado a Testes (TDD)?

Desenvolvimento Orientado a Testes (TDD) é uma abordagem de desenvolvimento de software na qual casos de teste são desenvolvidos para especificar e validar o que o código fará. Em termos simples, os casos de teste para cada funcionalidade são criados e testados primeiro e, se o teste falhar, o novo código é escrito para passar no teste e tornar o código simples e livre de erros.

O Desenvolvimento Orientado a Testes começa com o projeto e o desenvolvimento de testes para cada pequena funcionalidade de um aplicativo. A estrutura TDD instrui os desenvolvedores a escrever novo código somente se um teste automatizado falhar. Isso evita duplicação de código. O formulário completo do TDD é desenvolvimento orientado a testes.

O conceito simples do TDD é escrever e corrigir os testes que falharam antes de escrever um novo código (antes do desenvolvimento). Isso ajuda a evitar a duplicação de código, pois escrevemos uma pequena quantidade de código por vez para passar nos testes. (Os testes nada mais são do que condições de requisitos que precisamos testar para cumpri-los).

O desenvolvimento orientado a testes é um processo de desenvolvimento e execução de testes automatizados antes do desenvolvimento real do aplicativo. Conseqüentemente, o TDD às vezes também é chamado de Teste o primeiro desenvolvimento.

Como realizar o teste TDD

As etapas a seguir definem como realizar o teste TDD,

Adicione um teste.
Execute todos os testes e veja se algum novo teste falha.
Escreva algum código.
Execute testes e refatore o código.
Repetir.

Execute o teste TDD — Cinco etapas do desenvolvimento orientado a testes

O ciclo TDD define

Escreva um teste
Faça funcionar.
Altere o código para corrigi-lo, ou seja, refatorar.
Repita o processo.

Alguns esclarecimentos sobre TDD:

A abordagem TDD não trata de “Teste” nem de “Design”.
TDD não significa “escrever alguns dos testes e depois construir um sistema que passe nos testes.
TDD não significa “fazer muitos testes”.

TDD vs. Teste Tradicional

Abaixo está a principal diferença entre o desenvolvimento orientado a testes e os testes tradicionais:

A abordagem TDD é principalmente uma técnica de especificação. Ele garante que seu código-fonte seja exaustivamente testado em nível confirmatório.

Com os testes tradicionais, um teste bem-sucedido encontra um ou mais defeitos. É o mesmo que TDD. Quando um teste falha, você progrediu porque sabe que precisa resolver o problema.
O TDD garante que seu sistema realmente atenda aos requisitos definidos para ele. Isso ajuda a aumentar sua confiança em seu sistema.
No TDD, o foco está mais no código de produção que verifica se os testes funcionarão corretamente. Nos testes tradicionais, o foco está mais no design do caso de teste. Se o teste mostrará a execução adequada/inadequada da aplicação para atender aos requisitos.
No TDD, você atinge 100% de teste de cobertura. Cada linha de código é testada, ao contrário dos testes tradicionais.
A combinação de testes tradicionais e TDD leva à importância de testar o sistema em vez de aperfeiçoar o sistema.
In Modelagem Ágil (AM), você deve “testar com um propósito”. Você deve saber por que está testando algo e em que nível ele precisa ser testado.

O que é TDD de aceitação e TDD de desenvolvedor

Existem dois níveis de TDD

Aceitação TDD (ATDD): Com ATDD você escreve um único teste de aceitação. Este teste atende ao requisito da especificação ou satisfaz o comportamento do sistema. Depois disso, escreva código de produção/funcionalidade suficiente para cumprir o teste de aceitação. O teste de aceitação concentra-se no comportamento geral do sistema. ATDD também era conhecido como Desenvolvimento Orientado Comportamental (BDD).
TDD do desenvolvedor: Com o Developer TDD você escreve um único teste de desenvolvedor, ou seja, um teste de unidade e, em seguida, apenas o código de produção suficiente para realizar esse teste. O teste de unidade concentra-se em cada pequena funcionalidade do sistema. O desenvolvedor TDD é simplesmente chamado de TDD.O principal objetivo do ATDD e do TDD é especificar requisitos detalhados e executáveis para sua solução numa base just in time (JIT). JIT significa levar em consideração apenas os requisitos necessários no sistema. Portanto, aumente a eficiência.

Dimensionando TDD por meio de Desenvolvimento Ágil Orientado a Modelo (AMDD)

TDD é muito bom em especificação e validação detalhadas. Ele falha ao pensar em questões maiores, como design geral, uso do sistema ou UI. O AMDD aborda os problemas de escalabilidade do Agile que o TDD não aborda.

Assim, o AMDD é usado para problemas maiores.

O ciclo de vida do AMDD

No Desenvolvimento Orientado a Modelos (MDD), modelos extensos são criados antes que o código-fonte seja escrito. Que por sua vez possuem uma abordagem ágil?

Na figura acima, cada caixa representa uma atividade de desenvolvimento.

Envisioning é um dos processos TDD de testes de previsão/imaginação que serão realizados durante a primeira semana do projeto. O principal objetivo da previsão é identificar o escopo do sistema e a arquitetura do sistema. Requisitos de alto nível e modelagem de arquitetura são feitos para uma visão bem-sucedida.

É o processo onde não é feita uma especificação detalhada do software/sistema, mas sim a exploração dos requisitos do software/sistema que define a estratégia geral do projeto.

Iteração 0: Previsão

Existem duas subativações principais.

Previsão de requisitos iniciais.Pode levar vários dias para identificar os requisitos de alto nível e o escopo do sistema. O foco principal é explorar o modelo de uso, o modelo de domínio inicial e o modelo de interface do usuário (UI).
Inicie Archivisão arquitetônica. Também leva vários dias para identificar a arquitetura do sistema. Permite definir orientações técnicas para o projeto. O foco principal é explorar diagramas de tecnologia, fluxo de interface de usuário (UI), modelos de domínio e casos de mudança.

Modelagem de iteração

Aqui a equipe deve planejar o trabalho que será feito para cada iteração.

O processo ágil é utilizado para cada iteração, ou seja, durante cada iteração, um novo item de trabalho será adicionado com prioridade.
Os primeiros trabalhos com maior prioridade serão levados em consideração. Os itens de trabalho adicionados podem ser repriorizados ou removidos da pilha de itens a qualquer momento.
A equipe discute como implementarão cada requisito. A modelagem é usada para esse propósito.
A análise e o design da modelagem são feitos para cada requisito que será implementado para aquela iteração.

Ataque de modelo

Isso também é conhecido como modelagem Just in time.

Aqui a sessão de modelagem envolve uma equipe de 2/3 membros que discutem questões em papel ou quadro branco.
Um membro da equipe pedirá a outro para modelar com ele. Esta sessão de modelagem levará aproximadamente 5 a 10 minutos. Onde os membros da equipe se reúnem para compartilhar quadro branco/papel.
Eles exploram os problemas até não encontrarem a causa principal do problema. Bem a tempo, se um membro da equipe identificar o problema que deseja resolver, ele receberá ajuda rápida de outros membros da equipe.
Outros membros do grupo exploram a questão e todos continuam como antes. Também é chamado de modelagem stand-up ou sessões de controle de qualidade do cliente.

Desenvolvimento Orientado a Testes (TDD)

Ele promove testes de confirmação do código do seu aplicativo e especificações detalhadas.
Tanto o teste de aceitação (requisitos detalhados) quanto os testes de desenvolvedor (teste unitário) são entradas para o TDD.
TDD torna o código mais simples e claro. Permite ao desenvolvedor manter menos documentação.

Revisões

Isso é opcional. Inclui inspeções de código e revisões de modelos.
Isso pode ser feito para cada iteração ou para todo o projeto.
Esta é uma boa opção para dar feedback sobre o projeto.

Desenvolvimento Orientado a Testes (TDD) vs. Desenvolvimento Ágil Orientado a Modelo (AMDD)

TDD	AMDD
TDD encurta o ciclo de feedback da programação	AMDD encurta o ciclo de feedback de modelagem.
TDD é uma especificação detalhada	AMDD funciona para problemas maiores
TDD promove o desenvolvimento de código de alta qualidade	A AMDD promove comunicação de alta qualidade com partes interessadas e desenvolvedores.
TDD fala com programadores	AMDD conversa com Analista de Negócios, partes interessadas e profissionais de dados.
TDD não orientado visualmente	AMDD visualmente orientado
TDD tem escopo limitado a trabalhos de software	O AMDD tem um escopo amplo, incluindo as partes interessadas. Envolve trabalhar em direção a um entendimento comum
Ambos apoiam o desenvolvimento evolutivo	---------------

Estruturas TDD

Aqui está a lista das melhores estruturas de desenvolvimento orientado a testes (TDD)

Junito
TestNG
csUnit e NUnit
Rspec

Agora, vamos aprender o Desenvolvimento Orientado a Testes por meio de exemplos.

Exemplo de TDD

Aqui neste exemplo de Desenvolvimento Orientado a Testes, definiremos uma senha de classe. Para esta classe, tentaremos satisfazer as seguintes condições.

Uma condição para aceitação da senha:

A senha deve ter entre 5 e 10 caracteres.

Primeiro, neste exemplo de TDD, escrevemos o código que atende a todos os requisitos acima.

Cenário 1: Para executar o teste, criamos a classe PasswordValidator();

Executaremos a classe TestPassword() acima;

A saída é PASSADA conforme mostrado abaixo;

saída:

Cenário 2: Aqui podemos ver no método TestPasswordLength() que não há necessidade de criar uma instância da classe PasswordValidator. Instância significa criar um objeto de classe para referir os membros (variáveis/métodos) dessa classe.

Removeremos a classe PasswordValidator pv = new PasswordValidator () do código. Podemos ligar para o é válido () método diretamente por Validador de senha. É válido (“Abc123”). (Veja a imagem abaixo)

Então, refatoramos (alteramos o código) conforme abaixo:

Cenário 3: Após a refatoração, a saída mostra o status de falha (veja a imagem abaixo), isso ocorre porque removemos a instância. Portanto, não há referência ao método não estático é válido ().

Portanto, precisamos alterar esse método adicionando a palavra “estática” antes de Boolean como public static boolean isValid (String password). Refatorando a classe PasswordValidator() para remover o erro acima para passar no teste.

Saída:

Após fazer alterações na classe PassValidator(), se executarmos o teste a saída será PASSADA conforme mostrado abaixo.

Vantagens do TDD

A seguir estão as principais vantagens do Desenvolvimento Orientado a Testes em Engenharia de Software:

Notificação antecipada de bugs.

Os desenvolvedores testam seu código, mas no mundo dos bancos de dados, isso geralmente consiste em testes manuais ou scripts únicos. Usando o TDD você constrói, ao longo do tempo, um conjunto de testes automatizados que você e qualquer outro desenvolvedor podem executar novamente à vontade.

Código melhor projetado, mais limpo e mais extensível.

Ajuda a entender como o código será usado e como ele interage com outros módulos.
Isso resulta em melhores decisões de design e código mais sustentável.
O TDD permite escrever códigos menores com responsabilidade única, em vez de procedimentos monolíticos com múltiplas responsabilidades. Isso torna o código mais simples de entender.
O TDD também obriga a escrever apenas código de produção para passar nos testes com base nos requisitos do usuário.

Confiança para refatorar

Se você refatorar o código, poderá haver possibilidades de quebras no código. Portanto, com um conjunto de testes automatizados, você pode corrigir essas falhas antes do lançamento. O aviso adequado será dado se forem encontradas quebras quando testes automatizados forem usados.
O uso do TDD deve resultar em um código mais rápido e extensível, com menos bugs que podem ser atualizados com riscos mínimos.

Bom para trabalho em equipe

Na ausência de qualquer membro da equipe, outros membros da equipe podem facilmente pegar e trabalhar no código. Também auxilia no compartilhamento de conhecimento, tornando a equipe mais eficaz em geral.

Bom para desenvolvedores

Embora os desenvolvedores tenham que gastar mais tempo escrevendo casos de teste TDD, leva muito menos tempo para depurar e desenvolver novos recursos. Você escreverá um código mais limpo e menos complicado.

Resumo

TDD significa Desenvolvimento Orientado a Testes.
Significado TDD: É um processo de modificação do código para passar em um teste desenhado anteriormente.
É mais ênfase no código de produção do que no design de casos de teste.
O desenvolvimento orientado a testes é um processo de modificação do código para passar em um teste projetado anteriormente.
In Engenharia de Software, Às vezes é conhecido como “Teste o primeiro desenvolvimento.”
O teste TDD inclui a refatoração de um código, ou seja, alterar/adicionar alguma quantidade de código ao código existente sem afetar o comportamento do código.
A programação TDD quando utilizada, o código fica mais claro e simples de entender.

Você pode gostar: