Behaviour and Test Driven Development  [BDD | TDD] Desenvolvimento guiado a comportamento e testes Christiano Milfont Maré...
Testes
Requirements Design Implementation Testing Maintenance Deployment Waterfall
Requirements Design Implementation Testing Maintenance Deployment Waterfall
Testes
Testes
Requirements Design Implementation Testing Maintenance Deployment Waterfall
Requirements Design Implementation Testing Maintenance Deployment Test First
Requirements Design Implementation Testing Maintenance Deployment Test First
Requirements Design Implementation Testing Maintenance Deployment Test First
Use Case   Um caso de uso captura um contrato entre os interessados de um sistema sobre seus comportamentos . Writing Effe...
<ul><li>User Story </li></ul><ul><ul><ul><li>Card  [cartão] </li></ul></ul></ul><ul><ul><ul><li>Conversation  [conversação...
<ul><li>User Story </li></ul><ul><li>I ndependente </li></ul><ul><li>N egociável </li></ul><ul><li>V alioso ao comprador <...
Story Card
Story Card
Story Card
Linguagem Ubíqua &quot;A  language  structured  around  the domain  model  and used by  all  team members to  connect  all...
Um Membro do projeto cadastra uma “Issue” no sistema. Um Gerente de projetos aceita ou rejeita a entrada de Issues para se...
Um Membro do projeto cadastra uma “Issue” no sistema. Um Gerente de projetos aceita ou rejeita a entrada de Issues para se...
Um  Membro  do projeto cadastra uma “ Issue ” no sistema. Um   Gerente  de projetos  aceita   ou  rejeita   a entrada de  ...
<ul><li>Story Card </li></ul><ul><li>As a…   </li></ul><ul><li>I want… </li></ul><ul><li>so that… </li></ul>“ BDD fornece ...
<ul><li>Story Card </li></ul><ul><li>As a   [X] </li></ul><ul><li>I want  [Y] </li></ul><ul><li>so that  [Z] </li></ul><ul...
<ul><li>Story Card </li></ul><ul><li>As a   [role] </li></ul><ul><li>I want to  [activity] </li></ul><ul><li>To do  [a tas...
<ul><li>Story Card </li></ul><ul><li>As a  “ membro do projeto ” </li></ul><ul><li>I want  “ Criar uma issue ” </li></ul><...
Behaviour Driven Development Acceptance Criteria Given  [dado] When  [quando] Then  [então]
Acceptance Criteria Given   uma issue preenchida e um projeto informado When   um membro requisitar o cadastro Then   gara...
Acceptance Criteria Given  uma issue preenchida  And  um projeto informado  And  um membro autorizado When  um membro requ...
Titulo: Cadastrar Issues As a   membro do projeto I want  criar uma issue So that  eu possa acompanhar a resolução do mesm...
<ul><li>Given  um nome e um tipo e um nivel e um sumario a um projeto </li></ul><ul><li>When  o membro requisitar o cadast...
<ul><li>Given  um nome e um tipo e um nivel e um sumario a um projeto </li></ul><ul><li>When  o membro requisitar o cadast...
Declarativo vs Imperativo Dado  um nome preenchido com “Erro tal” E  um sumário preenchido com “bla bla bla” E  um nível s...
Test Driven Development “ Desenvolvimento guiado por testes é um caminho de gerenciamento do medo durante a programação.” ...
Test Driven Development Standup Meeting @ 9h Pair Up Test First [Prática] Code Refactor Integrar ou Disponibilizar Ir para...
Test Driven Development <ul><li>O ritmo em 3 A’s </li></ul><ul><li>Arrange [Criar um objeto] </li></ul><ul><li>Act  [Invoc...
Test Driven Development <ul><li>Escreva um teste que não funciona. </li></ul><ul><li>Escreva o código e faço-o funcionar. ...
<ul><li>Test Double </li></ul><ul><li>Dummy </li></ul><ul><li>Fake </li></ul><ul><li>Stubs </li></ul><ul><li>Spies </li></...
<ul><li>Fixture Setup </li></ul><ul><li>Setup </li></ul><ul><li>Tear Down </li></ul>@Before public void setUp() throws Exc...
http://en.wikipedia.org/wiki/Dexter_Morgan Perguntas?
Próximos SlideShares
Carregando em…5
×

Mare de Agilidade - BDD e TDD

3.200 visualizações

Publicada em

Publicada em: Tecnologia, Negócios
1 comentário
8 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
3.200
No SlideShare
0
A partir de incorporações
0
Número de incorporações
350
Ações
Compartilhamentos
0
Downloads
111
Comentários
1
Gostaram
8
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • 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&apos;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
  • Mare de Agilidade - BDD e TDD

    1. 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. 2. Testes
    3. 3. Requirements Design Implementation Testing Maintenance Deployment Waterfall
    4. 4. Requirements Design Implementation Testing Maintenance Deployment Waterfall
    5. 5. Testes
    6. 6. Testes
    7. 7. Requirements Design Implementation Testing Maintenance Deployment Waterfall
    8. 8. Requirements Design Implementation Testing Maintenance Deployment Test First
    9. 9. Requirements Design Implementation Testing Maintenance Deployment Test First
    10. 10. Requirements Design Implementation Testing Maintenance Deployment Test First
    11. 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
    12. 12. <ul><li>User Story </li></ul><ul><ul><ul><li>Card [cartão] </li></ul></ul></ul><ul><ul><ul><li>Conversation [conversação] </li></ul></ul></ul><ul><ul><ul><li>Confirmation [confirmação] </li></ul></ul></ul><ul><li>“ Ron Jeffries, 2001” </li></ul>
    13. 13. <ul><li>User Story </li></ul><ul><li>I ndependente </li></ul><ul><li>N egociável </li></ul><ul><li>V alioso ao comprador </li></ul><ul><li>E stimável </li></ul><ul><li>S mall [Pequena] </li></ul><ul><li>T estável </li></ul><ul><li>User Stories Applied </li></ul><ul><li>Mike Cohn </li></ul>
    14. 14. Story Card
    15. 15. Story Card
    16. 16. Story Card
    17. 17. Linguagem Ubíqua &quot;A language structured around the domain model and used by all team members to connect all the activities of the team with the software .&quot;
    18. 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. 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. 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
    21. 21. <ul><li>Story Card </li></ul><ul><li>As a… </li></ul><ul><li>I want… </li></ul><ul><li>so that… </li></ul>“ BDD fornece uma linguagem ubíqua para análise” Dan North
    22. 22. <ul><li>Story Card </li></ul><ul><li>As a [X] </li></ul><ul><li>I want [Y] </li></ul><ul><li>so that [Z] </li></ul><ul><li>Onde: </li></ul><ul><li>Y é alguma funcionalidade ou característica, </li></ul><ul><li>Z é o benefício ou valor dessa funcionalidade e </li></ul><ul><li>X é a pessoa ou perfil/papel beneficiado </li></ul>
    23. 23. <ul><li>Story Card </li></ul><ul><li>As a [role] </li></ul><ul><li>I want to [activity] </li></ul><ul><li>To do [a task] </li></ul><ul><li>In order to [business value] </li></ul><ul><li>As a [role] </li></ul><ul><li>I want to [activity] </li></ul>
    24. 24. <ul><li>Story Card </li></ul><ul><li>As a “ membro do projeto ” </li></ul><ul><li>I want “ Criar uma issue ” </li></ul><ul><li>so that “ Eu possa acompanhar a resolução ” </li></ul><ul><li>As a “ gerente do projeto ” </li></ul><ul><li>I want “ aceitar a entrada de uma issue ” </li></ul><ul><li>so that “ seja descartada ou resolvida apenas com minha permissão ” </li></ul>
    25. 25. Behaviour Driven Development Acceptance Criteria Given [dado] When [quando] Then [então]
    26. 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. 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 &quot;novas issues&quot; a serem resolvidas
    28. 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
    29. 29. <ul><li>Given um nome e um tipo e um nivel e um sumario a um projeto </li></ul><ul><li>When o membro requisitar o cadastro </li></ul><ul><li>Then garantir que seja criada uma issue </li></ul><ul><li> And armazenada no sistema </li></ul><ul><li> And uma mensagem seja informada </li></ul><ul><li> And a issue esteja na lista de não-confirmadas </li></ul><ul><li>@Given (&quot;a $name and a $type and a $level and a $summary and a $project &quot;)‏ </li></ul><ul><li>public void relatar(String name… ) throws IllegalArgumentIssueException { </li></ul><ul><ul><ul><li>throw new IllegalArgumentIssueException(&quot;erro&quot;); </li></ul></ul></ul><ul><li>} </li></ul>
    30. 30. <ul><li>Given um nome e um tipo e um nivel e um sumario a um projeto </li></ul><ul><li>When o membro requisitar o cadastro </li></ul><ul><li>Then garantir que seja criada uma issue </li></ul><ul><li> And armazenada no sistema </li></ul><ul><li> And uma mensagem seja informada </li></ul><ul><li> And a issue esteja na lista de não-confirmadas </li></ul><ul><li>@Given (&quot;a $name and a $type and a $level and a $summary and a $project &quot;)‏ </li></ul><ul><li>public void relatar(String name… ) throws IllegalArgumentIssueException { </li></ul><ul><ul><ul><li>Issue issue = member </li></ul></ul></ul><ul><ul><ul><ul><li>.createIssue( name )‏ </li></ul></ul></ul></ul><ul><ul><ul><ul><li>.withType( type )‏ </li></ul></ul></ul></ul><ul><ul><ul><ul><li>.withLevel( level )‏ </li></ul></ul></ul></ul><ul><ul><ul><ul><li>.withSummary( summary )‏ </li></ul></ul></ul></ul><ul><ul><ul><ul><li>.toProject( project) ; </li></ul></ul></ul></ul><ul><ul><ul><li>ensureThat(issue .getStatus(), equalTo(Status. UNCONFIRMED )); </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul><ul><li>} </li></ul>
    31. 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. 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. 33. Test Driven Development Standup Meeting @ 9h Pair Up Test First [Prática] Code Refactor Integrar ou Disponibilizar Ir para casa @ 17h
    34. 34. Test Driven Development <ul><li>O ritmo em 3 A’s </li></ul><ul><li>Arrange [Criar um objeto] </li></ul><ul><li>Act [Invocar um método] </li></ul><ul><li>Assert [Verificar o resultado] </li></ul><ul><li>Refactoring Workbook, Bill Wake </li></ul>
    35. 35. Test Driven Development <ul><li>Escreva um teste que não funciona. </li></ul><ul><li>Escreva o código e faço-o funcionar. </li></ul><ul><li>Refatore e elimine o código repetitivo. </li></ul>RED - GREEN - REFACTOR
    36. 36. <ul><li>Test Double </li></ul><ul><li>Dummy </li></ul><ul><li>Fake </li></ul><ul><li>Stubs </li></ul><ul><li>Spies </li></ul><ul><li>Mocks </li></ul>
    37. 37. <ul><li>Fixture Setup </li></ul><ul><li>Setup </li></ul><ul><li>Tear Down </li></ul>@Before public void setUp() throws Exception { Connection conn; try { ... IDatabaseConnection connection = new DatabaseConnection(conn); DatabaseOperation.INSERT.execute(connection, new FlatXmlDataSet( new FileInputStream( “ issuetrackr.xml&quot;))); conn.close(); } catch (Exception exc) { ... } }
    38. 38. http://en.wikipedia.org/wiki/Dexter_Morgan Perguntas?

    ×