{"id":551,"date":"2022-01-26T01:34:13","date_gmt":"2022-01-26T01:34:13","guid":{"rendered":"https:\/\/www.cybermedian.com\/pt\/?p=551"},"modified":"2022-03-31T12:09:16","modified_gmt":"2022-03-31T04:09:16","slug":"test-drive-development-approach-for-agile-software-development","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/pt\/test-drive-development-approach-for-agile-software-development\/","title":{"rendered":"Abordagem de desenvolvimento test-drive para desenvolvimento \u00e1gil de software"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n

Agora, as pessoas costumam falar sobre desenvolvimento \u00e1gil.<\/p>\n

O que \u00e9 Desenvolvimento \u00c1gil?<\/span><\/h4>\n

O desenvolvimento \u00e1gil<\/a>\u00a0\u00a0\u00e9 uma capacidade de desenvolvimento de software que responde a necessidades em r\u00e1pida mudan\u00e7a.\u00a0Seus nomes, conceitos, processos e terminologia espec\u00edficos variam.\u00a0Em compara\u00e7\u00e3o com o \u201c\u00a0n\u00e3o \u00e1gil<\/a>\u00a0\u201d, eles enfatizam a estreita colabora\u00e7\u00e3o entre equipes de programadores e especialistas em neg\u00f3cios, comunica\u00e7\u00e3o face a face (considerada mais eficaz do que documenta\u00e7\u00e3o escrita) e frequentemente entregam novas vers\u00f5es de software,\u00a0\u00a0equipes pequenas e auto-organizadas<\/a>\u00a0\u00a0para pequenos e escrita de recursos valiosos e abordagens de organiza\u00e7\u00e3o de equipe que se adaptam \u00e0s necessidades em constante mudan\u00e7a, com um foco maior no papel das pessoas no desenvolvimento de software.<\/p>\n

No entanto, existem v\u00e1rias vers\u00f5es semelhantes de m\u00e9todos de desenvolvimento \u00e1gil TDD, como TDD: BDD, DDD e ATDD.\u00a0Deixe-me apresentar brevemente esses m\u00e9todos antes de apresentar o TDD em detalhes:<\/p>\n

TDD: Desenvolvimento Orientado a Testes<\/strong><\/p>\n

Test Driven Development<\/a>\u00a0\u00a0(TDD) \u00e9 um processo de desenvolvimento de software, que se baseia na transforma\u00e7\u00e3o 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.\u00a0Isso \u00e9 o oposto de desenvolver software primeiro e depois criar casos de teste.\u00a0Alguns modelos populares suportam muito bem o TDD, como MVC e\u00a0\u00a0MVP<\/a>\u00a0.<\/p>\n

<\/figure>\n

BDD: Desenvolvimento Orientado ao Comportamento (Behavior Driven Development)<\/strong><\/p>\n

O desenvolvimento orientado por comportamento (BDD) tamb\u00e9m \u00e9 um processo \u00e1gil de desenvolvimento de software.\u00a0Ele incentiva a colabora\u00e7\u00e3o entre desenvolvedores, testadores de garantia de qualidade e representantes de clientes em projetos de software.\u00a0Ele incentiva as equipes a usar conversas e exemplos concretos para formalizar um entendimento comum de como o aplicativo deve funcionar.\u00a0Ele vem do desenvolvimento orientado a testes (TDD).<\/p>\n

<\/figure>\n

ATDD: Desenvolvimento Orientado a Testes de Aceita\u00e7\u00e3o<\/strong><\/p>\n

Para promover a realiza\u00e7\u00e3o do c\u00f3digo funcional por meio de casos de teste de unidade, a equipe precisa definir padr\u00f5es de qualidade esperados e regras de aceita\u00e7\u00e3o, e promover a pr\u00e1tica de TDD dos desenvolvedores e o desempenho dos testadores por meio de um plano de teste de aceita\u00e7\u00e3o claro e consistente (incluindo uma s\u00e9rie de testes cen\u00e1rios).\u00a0Para os desenvolvedores, enfatiza como implementar o sistema e como test\u00e1-lo.<\/p>\n

<\/figure>\n

DDD: design de unidade de dom\u00ednio<\/strong><\/p>\n

DDD refere-se ao design orientado a dom\u00ednio, ou seja, desenvolvimento orientado a dom\u00ednio.\u00a0O DDD \u00e9 realmente constru\u00eddo sobre essa base porque se concentra no design da camada de servi\u00e7o, concentra-se na implementa\u00e7\u00e3o de neg\u00f3cios, combina an\u00e1lise e design e n\u00e3o o mant\u00e9m mais em um estado dividido, para implementar de maneira correta e abrangente as necessidades do cliente e construir um modelo de neg\u00f3cios escalabilidade.<\/p>\n

<\/figure>\n

Plano de implementa\u00e7\u00e3o de TDD<\/span><\/h3>\n

Atrav\u00e9s de testes para promover todo o desenvolvimento, mas o desenvolvimento orientado a testes n\u00e3o \u00e9 apenas um simples trabalho de teste, mas um processo de quantifica\u00e7\u00e3o de an\u00e1lise de requisitos, design e controle de qualidade.<\/em><\/p><\/blockquote>\n

Princ\u00edpios de desenvolvimento<\/strong><\/p>\n

Escreva o c\u00f3digo de teste primeiro e, em seguida, escreva o c\u00f3digo para a fun\u00e7\u00e3o.<\/em><\/p><\/blockquote>\n

    \n
  1. Escreva o c\u00f3digo de teste de acordo com o documento de requisitos, para n\u00e3o realizar a fun\u00e7\u00e3o;<\/li>\n
  2. N\u00e3o quero ser gordo com uma mordida.\u00a0Ao testar grandes blocos funcionais, voc\u00ea deve primeiro dividi-los em blocos funcionais menores para teste;<\/li>\n
  3. Lembre-se de n\u00e3o escrever c\u00f3digo para completar a fun\u00e7\u00e3o, use o c\u00f3digo mais simples poss\u00edvel para implementar a fun\u00e7\u00e3o;<\/li>\n
  4. Se os requisitos puderem ser testados, escreva o c\u00f3digo de teste e abandone aqueles que n\u00e3o podem ser testados ou sinta que n\u00e3o precisam ser testados;<\/li>\n
  5. Antes de alterar\/adicionar qualquer c\u00f3digo de fun\u00e7\u00e3o, voc\u00ea deve primeiro pensar se deseja alterar\/adicionar casos de teste;<\/li>\n
  6. C\u00f3digo de fun\u00e7\u00e3o\/teste, estrutura irracional, c\u00f3digo duplicado, etc., refatore no tempo ap\u00f3s a aprova\u00e7\u00e3o do teste.<\/li>\n<\/ol>\n

    Processo de desenvolvimento de TDD<\/strong><\/p>\n

      \n
    1. Analisar e determinar um cen\u00e1rio de teste alvo;<\/li>\n
    2. Adicione um teste de unidade para verificar a entrada e sa\u00edda do cen\u00e1rio de teste;<\/li>\n
    3. Execute o teste e obtenha o resultado do teste com falha;<\/li>\n
    4. Escreva o c\u00f3digo de fun\u00e7\u00e3o mais simples para passar no teste;<\/li>\n
    5. Execute o teste novamente e veja se o teste passa;<\/li>\n
    6. Realizar refatora\u00e7\u00e3o de c\u00f3digo, incluindo c\u00f3digo funcional e c\u00f3digo de teste de unidade;<\/li>\n
    7. Repita as etapas acima at\u00e9 que o desenvolvimento seja conclu\u00eddo.<\/li>\n<\/ol>\n

      Benef\u00edcios do TDD<\/strong><\/p>\n

        \n
      1. Reduza a carga dos desenvolvedores<\/strong>\u00a0.\u00a0Por meio de um processo claro, vamos nos concentrar em apenas um ponto de cada vez, e o fardo de pensar \u00e9 menor.<\/li>\n
      2. A rede de prote\u00e7\u00e3o<\/strong>\u00a0.\u00a0A cobertura de testes unit\u00e1rios completos fornece uma rede protetora para o c\u00f3digo do produto, facilitando o atendimento a mudan\u00e7as nos requisitos ou a melhoria do design do c\u00f3digo.\u00a0Portanto, se os requisitos do seu projeto forem est\u00e1veis, executados de uma s\u00f3 vez e n\u00e3o houver altera\u00e7\u00f5es subsequentes, os benef\u00edcios do TDD ser\u00e3o menores.<\/li>\n
      3. Esclare\u00e7a os requisitos com anteced\u00eancia<\/strong>\u00a0.\u00a0Escrever testes primeiro pode nos ajudar a pensar sobre os requisitos e esclarecer os detalhes dos requisitos com anteced\u00eancia, em vez de descobrir requisitos pouco claros apenas na metade do c\u00f3digo.<\/li>\n
      4. Feedback r\u00e1pido<\/strong>\u00a0.\u00a0Muitas pessoas dizem que quando TDD, meu volume de c\u00f3digo aumenta, ent\u00e3o a efici\u00eancia do desenvolvimento diminui.\u00a0No entanto, se voc\u00ea n\u00e3o tiver testes de unidade, precisar\u00e1 test\u00e1-los manualmente, gastar muito tempo preparando dados, iniciando aplicativos, modificando interfaces e assim por diante, e o feedback \u00e9 lento.\u00a0<\/span>Para ser preciso, o feedback r\u00e1pido \u00e9 um benef\u00edcio do teste de unidade.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/section>\n
        \n
        \n
        \n<\/div>\n
        \n
        \n

        Princ\u00edpios \u00c1geis e Scrum<\/span><\/h4>\n