Behaviour Driven Development (BDD)

Behaviour Driven Development (BDD)

1. busca tornar as práticas destas outras metodologias mais acessíveis e intuitivas para os novatos e especialistas

2. Foco na entrega de valor

   • Formação de um vocabulário comum
   • Reduz a distância entre o Negócio e a TI

3. Geralmente o cliente deve prover

   • informações sobre o problema que ele quer resolver
   • juntos podem pensar nos exemplos concretos que vão nortear o processo de desenvolvimento.

4. Exemplos são essencias na metodologia

   • mais fácil entender um domínio de negócios complexo

5. busca melhorar a comunicação e a interação entre os stakeholders

   • como o software deve se comportar por meio de cenários escritos em linguagem natural
   • Isso minimiza ruídos de comunicação, previne falhas e reduz riscos – este é o grande foco dessa metodologia

6. Principais práticas

   • Envolver as partes interessadas no processo através de Outside-in Development (Desenvolvimento de Fora pra Dentro);
   • Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código
   • Automatizar os exemplos para prover um feedback rápido e possivelmente testes de regressão
   • Usar “deve” na hora de descrever o comportamento ajuda a esclarecer responsabilidades e permitir que funcionalidades sejam questionadas;
   • Usar simuladores de teste (mocks, stubs, fakes, dummies, spies) para auxiliar na colaboração entre módulos e códigos que ainda não foram escritos

7. História

   • “Eu, como Analista de Relacionamento, desejo poder manipular todas as informações de um chamado para que eu possa resolvê-lo
   • deve possuir algum valor para o negócio

8. Cenário

   • a linguagem é voltada para o negócio, sem detalhes técnicos
   • "Dado que não existam chamados abertos, quando abrirem um chamado, então eu devo poder manipulá-lo”

9. Automatizar testes escritos

   • Garante a validação do software
   • Ferramentas
     • SpecFlow
     • JBehave
     • JSpec
     • RSpec

10. associa os benefícios de uma documentação formal, escrita e mantida pelo “negócio”, com testes de unidade que “demonstram” que essa documentação é efetivamente válida.

11. perspectiva orientada a especificações

12. Foco

    • Usuário
    • Valores de negócio

13. Os testes ainda orientam o desenvolvimento, visto que a especificações se tornam testes que são realizados antes da codificação do sistema em si

14. Benefícios

    • melhor comunicação entre equipes
    • compartilhamento de conhecimento
    • documentação dinâmica
    • visão do todo

15. Útil

    • projetos de software ágeis
      • iterativos
      • incrementais.

Imagens e arquivos do mapa