Desenvolvimento Orientado a Testes
O Test Driven Development (TDD) é uma abordagem de desenvolvimento de software em que os 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. O TDD instrui os desenvolvedores a escrever um novo código apenas se um teste automatizado falhar. Isso evita a duplicação de código. A forma completa do TDD é o desenvolvimento orientado a testes.
O conceito simples de 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 conforme 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 Test First Development.
Neste tutorial, você aprenderá mais sobre-
- Como realizar o teste TDD
- TDD vs. Teste Tradicional
- O que é TDD de aceitação e TDD de Desenvolvedor
- Escalonando TDD por meio do Agile Model Driven Development (AMDD)
- Test Driven Development (TDD) vs. Desenvolvimento Agile Model Driven (AMDD)
- Exemplo de TDD
- Benefícios do TDD
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 refatorar o código.
- Repita.
O ciclo TDD define
- Escreva um teste
- Faça funcionar.
- Altere o código para torná-lo correto, ou seja, Refatorar.
- Repita o processo.
Alguns esclarecimentos sobre o TDD:
- TDD não é sobre "Teste" nem sobre "Design".
- TDD não significa "escrever alguns dos testes e, em seguida, construir um sistema que passe nos testes.
- TDD não significa "fazer muitos testes".
TDD vs. Teste Tradicional
A abordagem TDD é principalmente uma técnica de especificação. Isso garante que seu código-fonte seja totalmente testado no nível de confirmação.
- Com o teste tradicional, um teste bem-sucedido encontra um ou mais defeitos. É o mesmo que TDD. Quando um teste falha, você progride porque sabe que precisa resolver o problema.
- O TDD garante que seu sistema realmente atenda aos requisitos definidos para ele. Ajuda a aumentar a sua confiança sobre o seu sistema.
- No TDD, mais foco está no código de produção que verifica se o teste funcionará corretamente. Nos testes tradicionais, mais foco está no design do caso de teste. Se o teste mostrará a execução adequada / inadequada do aplicativo para atender aos requisitos.
- No TDD, você atinge o teste de cobertura de 100%. 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 da perfeição do sistema.
- No Agile Modeling (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 aos requisitos 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 se concentra no comportamento geral do sistema. ATDD também era conhecido como Behavioral Driven Development (BDD).
- Developer TDD: 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 cumprir esse teste. O teste de unidade concentra-se em cada pequena funcionalidade do sistema. O desenvolvedor TDD é simplesmente chamado de TDD.
O objetivo principal do ATDD e do TDD é especificar requisitos detalhados e executáveis para sua solução em uma base just in time (JIT). JIT significa levar em consideração apenas aqueles requisitos que são necessários no sistema. Portanto, aumente a eficiência.
Escalonando TDD por meio do Agile Model Driven Development (AMDD)
O TDD é muito bom em especificações e validação detalhadas. Ele falha em pensar em questões maiores, como design geral, uso do sistema ou IU. AMDD aborda os problemas de dimensionamento ágil que o TDD não.
Assim, a AMDD é usada para problemas maiores.
O ciclo de vida da AMDD.
Em Model-driven Development (MDD), modelos abrangentes são criados antes que o código-fonte seja escrito. Que por sua vez tem uma abordagem ágil?
Na figura acima, cada caixa representa uma atividade de desenvolvimento.
A previsão é 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. Os requisitos de alto nível e a modelagem de arquitetura são feitos para uma visualização bem-sucedida.
É o processo em que 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 dos 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 (IU).
- Visão inicial da arquitetura.
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 do usuário (IU), 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 é usado para cada iteração, ou seja, durante cada iteração, um novo item de trabalho será adicionado com prioridade.
- O primeiro trabalho com maior prioridade será levado em consideração. Os itens de trabalho adicionados podem ser priorizados novamente ou removidos da pilha de itens a qualquer momento.
- A equipe discute como irão implementar 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.
- Model storming:
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 eles. Esta sessão de modelagem levará aproximadamente 5 a 10 minutos. Onde os membros da equipe se reúnem para compartilhar o 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 de unidade) são entradas para o TDD.
- O TDD torna o código mais simples e claro. Ele permite que o desenvolvedor mantenha menos documentação.
- Avaliações.
- Isso é opcional. Inclui inspeções de código e revisões de modelo.
- Isso pode ser feito para cada iteração ou para todo o projeto.
- Esta é uma boa opção para dar feedback sobre o projeto.
Test Driven Development (TDD) vs. Desenvolvimento Agile Model Driven (AMDD)
| TDD | AMDD |
|
|
|
|
|
|
|
|
|
|
|
|
| -------------------------------------------- |
Exemplo de TDD
Aqui neste exemplo, definiremos uma senha de classe. Para esta aula, tentaremos satisfazer as seguintes condições.
Uma condição para aceitação da senha:
- A senha deve ter entre 5 a 10 caracteres.
Primeiro, 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;
Produto :
Cenário 2 : Aqui podemos ver que no método TestPasswordLength () não há necessidade de criar uma instância da classe PasswordValidator. Instância significa criar um objeto de classe para fazer referência aos membros (variáveis / métodos) dessa classe.
Removeremos a classe PasswordValidator pv = new PasswordValidator () do código. Podemos chamar o método isValid () diretamente pelo PasswordValidator. IsValid ("Abc123") . (Veja a imagem abaixo)
Portanto, nós refatoramos (alteramos o código) conforme abaixo:
Cenário 3 : Depois de refatorar, a saída mostra o status de falha (veja a imagem abaixo) porque removemos a instância. Portanto, não há referência ao método não estático isValid ().
Portanto, precisamos alterar este método adicionando a palavra "estática" antes de Boolean como public static boolean isValid (String password). Classe de refatoração PasswordValidator () para remover o erro acima e passar no teste.
Resultado:
Depois de fazer alterações na classe PassValidator (), se executarmos o teste, a saída será PASSADA conforme mostrado abaixo.
Vantagens do TDD
- Notificação de bug antecipada.
Os desenvolvedores testam seu código, mas no mundo do banco de dados, isso geralmente consiste em testes manuais ou scripts únicos. Usando o TDD, você constrói, com o tempo, um conjunto de testes automatizados que você e qualquer outro desenvolvedor pode executar novamente à vontade.
- Código melhor projetado, mais limpo e mais extensível.
- Isso ajuda a entender como o código será usado e como ele interage com outros módulos.
- Isso resulta em melhor decisão 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 responsabilidades múltiplas. Isso torna o código mais simples de entender.
- O TDD também obriga a escrever apenas o 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, pode haver possibilidades de quebras no código. Portanto, tendo um conjunto de testes automatizados, você pode consertar essas quebras antes do lançamento. Um aviso adequado será fornecido se houver interrupções durante o uso de testes automatizados.
- O uso de 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. É um processo de modificação do código para passar em um teste projetado anteriormente.
- É mais ênfase no código de produção do que no design do caso de teste.
- O desenvolvimento orientado a testes é um processo de modificação do código para passar em um teste projetado anteriormente.
- Em Engenharia de Software, às vezes é conhecido como "Teste Primeiro o Desenvolvimento".
- O TDD inclui refatorar um código, ou seja, alterar / adicionar alguma quantidade de código ao código existente sem afetar o comportamento do código.
- TDD quando usado, o código torna-se mais claro e simples de entender.
Este artigo é uma contribuição de Kanchan Kulkarni