Agora, as pessoas costumam falar sobre desenvolvimento ágil.
O que é Desenvolvimento Ágil?
O desenvolvimento ágil é uma capacidade de desenvolvimento de software que responde a necessidades em rápida mudança. Seus nomes, conceitos, processos e terminologia específicos variam. Em comparação com o “ não ágil ”, eles enfatizam a estreita colaboração entre equipes de programadores e especialistas em negócios, comunicação face a face (considerada mais eficaz do que documentação escrita) e frequentemente entregam novas versões de software, equipes pequenas e auto-organizadas para pequenos e escrita de recursos valiosos e abordagens de organização de equipe que se adaptam às necessidades em constante mudança, com um foco maior no papel das pessoas no desenvolvimento de software.
No entanto, existem várias versões semelhantes de métodos de desenvolvimento ágil TDD, como TDD: BDD, DDD e ATDD. Deixe-me apresentar brevemente esses métodos antes de apresentar o TDD em detalhes:
TDD: Desenvolvimento Orientado a Testes
Test Driven Development (TDD) é um processo de desenvolvimento de software, que se baseia na transformação de requisitos de software em casos de teste antes que o software seja totalmente desenvolvido e no rastreamento de todo o desenvolvimento de software testando repetidamente o software para todos os casos de teste. Isso é o oposto de desenvolver software primeiro e depois criar casos de teste. Alguns modelos populares suportam muito bem o TDD, como MVC e MVP .
BDD: Desenvolvimento Orientado ao Comportamento (Behavior Driven Development)
O desenvolvimento orientado por comportamento (BDD) também é um processo ágil de desenvolvimento de software. Ele incentiva a colaboração entre desenvolvedores, testadores de garantia de qualidade e representantes de clientes em projetos de software. Ele incentiva as equipes a usar conversas e exemplos concretos para formalizar um entendimento comum de como o aplicativo deve funcionar. Ele vem do desenvolvimento orientado a testes (TDD).
ATDD: Desenvolvimento Orientado a Testes de Aceitação
Para promover a realização do código funcional por meio de casos de teste de unidade, a equipe precisa definir padrões de qualidade esperados e regras de aceitação, e promover a prática de TDD dos desenvolvedores e o desempenho dos testadores por meio de um plano de teste de aceitação claro e consistente (incluindo uma série de testes cenários). Para os desenvolvedores, enfatiza como implementar o sistema e como testá-lo.
DDD: design de unidade de domínio
DDD refere-se ao design orientado a domínio, ou seja, desenvolvimento orientado a domínio. O DDD é realmente construído sobre essa base porque se concentra no design da camada de serviço, concentra-se na implementação de negócios, combina análise e design e não o mantém mais em um estado dividido, para implementar de maneira correta e abrangente as necessidades do cliente e construir um modelo de negócios escalabilidade.
Plano de implementação de TDD
Através de testes para promover todo o desenvolvimento, mas o desenvolvimento orientado a testes não é apenas um simples trabalho de teste, mas um processo de quantificação de análise de requisitos, design e controle de qualidade.
Princípios de desenvolvimento
Escreva o código de teste primeiro e, em seguida, escreva o código para a função.
- Escreva o código de teste de acordo com o documento de requisitos, para não realizar a função;
- Não quero ser gordo com uma mordida. Ao testar grandes blocos funcionais, você deve primeiro dividi-los em blocos funcionais menores para teste;
- Lembre-se de não escrever código para completar a função, use o código mais simples possível para implementar a função;
- Se os requisitos puderem ser testados, escreva o código de teste e abandone aqueles que não podem ser testados ou sinta que não precisam ser testados;
- Antes de alterar/adicionar qualquer código de função, você deve primeiro pensar se deseja alterar/adicionar casos de teste;
- Código de função/teste, estrutura irracional, código duplicado, etc., refatore no tempo após a aprovação do teste.
Processo de desenvolvimento de TDD
- Analisar e determinar um cenário de teste alvo;
- Adicione um teste de unidade para verificar a entrada e saída do cenário de teste;
- Execute o teste e obtenha o resultado do teste com falha;
- Escreva o código de função mais simples para passar no teste;
- Execute o teste novamente e veja se o teste passa;
- Realizar refatoração de código, incluindo código funcional e código de teste de unidade;
- Repita as etapas acima até que o desenvolvimento seja concluído.
Benefícios do TDD
- Reduza a carga dos desenvolvedores . Por meio de um processo claro, vamos nos concentrar em apenas um ponto de cada vez, e o fardo de pensar é menor.
- A rede de proteção . A cobertura de testes unitários completos fornece uma rede protetora para o código do produto, facilitando o atendimento a mudanças nos requisitos ou a melhoria do design do código. Portanto, se os requisitos do seu projeto forem estáveis, executados de uma só vez e não houver alterações subsequentes, os benefícios do TDD serão menores.
- Esclareça os requisitos com antecedência . Escrever testes primeiro pode nos ajudar a pensar sobre os requisitos e esclarecer os detalhes dos requisitos com antecedência, em vez de descobrir requisitos pouco claros apenas na metade do código.
- Feedback rápido . Muitas pessoas dizem que quando TDD, meu volume de código aumenta, então a eficiência do desenvolvimento diminui. No entanto, se você não tiver testes de unidade, precisará testá-los manualmente, gastar muito tempo preparando dados, iniciando aplicativos, modificando interfaces e assim por diante, e o feedback é lento. Para ser preciso, o feedback rápido é um benefício do teste de unidade.
Princípios Ágeis e Scrum
- O Manifesto Ágil e os Doze Princípios
- 10 regras básicas mais frequentemente mencionadas no Scrum
- Como funciona a equipe Scrum? — Um breve guia