Mare de Agilidade - BDD e TDD
•Als PPT, PDF herunterladen•
9 gefällt mir•2,236 views
O documento discute técnicas de desenvolvimento guiado por comportamento e testes (BDD e TDD). Apresenta os conceitos de histórias de usuário, cartões de histórias, critérios de aceitação e testes para guiar o desenvolvimento de software.
![Behaviour and Test Driven Development [BDD | TDD] Desenvolvimento guiado a comportamento e testes Christiano Milfont Maré de Agilidade 2009, Fortaleza Copyleft 2009 Milfont.org](https://image.slidesharecdn.com/maredeagilidademilfont-090809062633-phpapp01/85/mare-de-agilidade-bdd-e-tdd-1-320.jpg)
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Mare de Agilidade - BDD e TDD
Ähnlich wie Mare de Agilidade - BDD e TDD (20)
Mehr von Milfont Consulting
Mehr von Milfont Consulting (20)
Mare de Agilidade - BDD e TDD
- 1. Behaviour and Test Driven Development [BDD | TDD] Desenvolvimento guiado a comportamento e testes Christiano Milfont Maré de Agilidade 2009, Fortaleza Copyleft 2009 Milfont.org
- 2. Testes
- 3. Requirements Design Implementation Testing Maintenance Deployment Waterfall
- 4. Requirements Design Implementation Testing Maintenance Deployment Waterfall
- 5. Testes
- 6. Testes
- 7. Requirements Design Implementation Testing Maintenance Deployment Waterfall
- 8. Requirements Design Implementation Testing Maintenance Deployment Test First
- 9. Requirements Design Implementation Testing Maintenance Deployment Test First
- 10. Requirements Design Implementation Testing Maintenance Deployment Test First
- 11. Use Case Um caso de uso captura um contrato entre os interessados de um sistema sobre seus comportamentos . Writing Effective Use Cases Alistair Cockburn User Story Uma estoria descreve funcionalmente o que será valioso para os usuários e aos compradores de um software . User Stories Applied Mike Cohn Behaviour Driven Development
- 14. Story Card
- 15. Story Card
- 16. Story Card
- 17. Linguagem Ubíqua "A language structured around the domain model and used by all team members to connect all the activities of the team with the software ."
- 18. Um Membro do projeto cadastra uma “Issue” no sistema. Um Gerente de projetos aceita ou rejeita a entrada de Issues para serem trabalhadas. Um Funcionário do hospital dar entrada do Paciente na Emergência. O Cenário de entrada por pacientes depende do Login do usuário com ROLE Admin na Action antes do forward. Um funcionário atende uma solicitação de saída de medicamento pelo prontuário do paciente com limite do cardápio do médico. A Tabela TB_ITEMS tem ligação com a Tabela TB_NOTAS
- 19. Um Membro do projeto cadastra uma “Issue” no sistema. Um Gerente de projetos aceita ou rejeita a entrada de Issues para serem trabalhadas. Um Funcionário do hospital dar entrada do Paciente na Emergência. O Cenário de entrada por pacientes depende do Login do usuário com ROLE Admin na Action antes do forward. Um funcionário atende uma solicitação de saída de medicamento pelo prontuário do paciente com limite do cardápio do médico. A Tabela TB_ITEMS tem ligação com a Tabela TB_NOTAS
- 20. Um Membro do projeto cadastra uma “ Issue ” no sistema. Um Gerente de projetos aceita ou rejeita a entrada de Issues para serem trabalhadas. Um Funcionário do hospital dar entrada do Paciente na Emergência . O Cenário de entrada por pacientes depende do Login do usuário com ROLE Admin na Action antes do forward. Um funcionário atende uma solicitação de saída de medicamento pelo prontuário do paciente com limite do cardápio do médico. A Tabela TB_ITEMS tem ligação com a Tabela TB_NOTAS
- 25. Behaviour Driven Development Acceptance Criteria Given [dado] When [quando] Then [então]
- 26. Acceptance Criteria Given uma issue preenchida e um projeto informado When um membro requisitar o cadastro Then garantir que ela seja armazenada no sistema And uma mensagem seja informada And a issue esteja na lista de não-confirmadas
- 27. Acceptance Criteria Given uma issue preenchida And um projeto informado And um membro autorizado When um membro requisitar o cadastro Then garantir que ela seja armazenada no sistema And uma mensagem seja informada And a issue esteja na lista de "novas issues" a serem resolvidas
- 28. Titulo: Cadastrar Issues As a membro do projeto I want criar uma issue So that eu possa acompanhar a resolução do mesmo. Cenário 1 Given uma issue preenchida e um projeto informado When um membro requisitar o cadastro Then garantir que ela seja armazenada no sistema And uma mensagem seja informada And a issue esteja na lista de não-confirmadas Cenário 2 Given um nome e um tipo e um nivel e um sumario a um projeto When o membro requisitar o cadastro Then garantir que seja criada uma issue And armazenada no sistema And uma mensagem seja informada And a issue esteja na lista de não-confirmadas
- 31. Declarativo vs Imperativo Dado um nome preenchido com “Erro tal” E um sumário preenchido com “bla bla bla” E um nível selecionado como “PENDENTE” E um projeto selecionado com o nome “Projeto Novo” Quando o cliente requisitar o cadastro Então garantir que seja criada uma issue E armazenada no sistema E uma mensagem seja informada E a issue esteja na lista de não-confirmadas Dado uma Issue preenchida adequadamente Quando o cliente requisitar o cadastro Então garantir que seja criada uma issue E armazenada no sistema E uma mensagem seja informada E a issue esteja na lista de não-confirmadas
- 32. Test Driven Development “ Desenvolvimento guiado por testes é um caminho de gerenciamento do medo durante a programação.” Kent Beck - Test Driven Development by Example
- 33. Test Driven Development Standup Meeting @ 9h Pair Up Test First [Prática] Code Refactor Integrar ou Disponibilizar Ir para casa @ 17h
Hinweis der Redaktion
- Falar da industria de softwares, modelo enterprisey, dizer que isso tudo é velharia. Craftmanship manifesto, Agile manifesto Requirements are behaviour,too BDD provides a “ubiquitous language” for analysis Lembrar que tudo não passa de dicas para modelar o domínio do coração do sistema durante o jogo do planejamento e desenvolvimento diário. BDD é uma forma de levar TDD adiante, ir além dos testes e ajudar na modelagem da aplicação se concentrando nas funcionalidades e não permitindo que se saia do estritamente necessário. Test se tornou Behaviou, Fixture se tornou context, assert se tornou should Testes como especificação Design não é subset deRefactoring e sim o refactoring faz parte do design
- Use Case Hell: Tentar centralizar todas as visões Use Case é o detalhamento da interação entre o usuário e o sistema em uma sequência de passos para capturar os requisitos funcionais do sistema antes da implementação Caso de uso é baseado no sistema enxergando o usuario, o user story é o usuario enxergando o sistema. Inverte a lógica de observação. Uma estória representa um ator do caso de uso dentro de um caso de uso e como o sistema o beneficiará independente de como funciona o caso de uso. Caso de uso é escrito pelo tecnico, story pelo cliente. A use case captures a contract between the stakeholders of a system about its behavior. A user story describes functionality that will be valuable to either a user or purchaser of a system or software.
- Contar história do analista pedreiro Critérios de aceitação devem ser executáveis UML fracassou em ser uma linguagem de modelagem por provocar um gap entre o modelo e a execução.
- Ideally, stories are independent from one another. This isn't always possible but to the extent it is, stories should be written so that they can be developed in any order. The details of a story are negotiated between the user and the developers. Stories should be written so that their value to users or the customer is clear. The best way to achieve this is to have the customer write the stories. Stories may be annotated with details, but too much detail obscures the meaning of the story and can give the impression that no conversation is necessary between the developers and the customer. One of the best ways to annotate a story is to write test cases for the story. If they are too big, compound and complex stories may be split into multiple smaller stories. If they are too small, multiple tiny stories may be combined into one bigger story. Stories need to be testable. Contar história do analista pedreiro Critérios de aceitação devem ser executáveis UML fracassou em ser uma linguagem de modelagem por provocar um gap entre o modelo e a execução.
- A story card with notes providing additional detail.
- A story card with notes providing additional detail.
- A story card with notes providing additional detail.
- To create a supple, knowledge-rich design calls for a versatile, shared team language, and a lively experimentation with language that seldom happens on software projects.
- where Y is some feature, Z is the benefit or value of the feature, and X is the person (or role) who will benefit. Its strength is that it forces you to identify the value of delivering a story when you first define it. When there is no real business value for a story, it often comes down to something like ” . . . I want [some feature] so that [I just do, ok?].” This can make it easier to descope some of the more esoteric requirements. Template para Story Card como saída inicial
- where Y is some feature, Z is the benefit or value of the feature, and X is the person (or role) who will benefit. Its strength is that it forces you to identify the value of delivering a story when you first define it. When there is no real business value for a story, it often comes down to something like ” . . . I want [some feature] so that [I just do, ok?].” This can make it easier to descope some of the more esoteric requirements. Template para Story Card como saída inicial
- Podemos customizar o Variações do Template para Story Card template de story de acordo com a necessidade
- Story Card e Scenarios
- Story Card e Scenarios
- Story Card e Scenarios