A apresentação introduz o Behavior-Driven Development (BDD) utilizando a ferramenta JBehave. O palestrante explica os conceitos por trás do BDD, como se relaciona com TDD e DDD, e demonstra um exemplo prático utilizando JBehave em português.

1. Behaviour-DrivenDevelopment, com Jbehave RioJUG, reunião de Janeiro/2011

2. Apresentação Marcelo Zeferino (marceloczeferino@gmail.com): Formado em análise de sistemas, atua com TI desde 1999 e já participou de projetos para grandes organizações como Fundação BioRio/Johns Hopkins Schoolof Medicine, Oi, Sul América e Fundação Roberto Marinho. Já atuou pela IBM Brasil e atualmente é Líder Técnico na Lumis Tecnologia, consultor e instrutor Java em cursos de extensão oferecidos pela UERJ. Mantém o blog continuepensando.wordpress.com, com idéias sobre desenvolvimento de software.

3. Agenda Conceitos por trás do BDD; Ciclo de desenvolvimento com BDD; BDD versus TDD; BDD + TDD; BDD + DDD; JBehave (2.5.9); Um exemplo prático;

4. Primeiro, vamos pensar em um problema: O Cliente possui as regras de algo que deseja implementar e, após lhe explicar, você modela, escreve e o apresenta para validação. Cliente: Ok, acho que entendeu bem; Você: Oh, beleza, vamos implementar dessa forma então!

5. Alguém já viu essa história antes?

6. Após algum tempo... Cliente: Argh, não foi isso que eu pedi! Você: Mas foi o que lhe passei e você aprovou!

7. Duas soluções (dentre várias outras) Métodos ágeis ajudam muito, mas mesmo com iterações pequenas ainda podemos ter alguns problemas de entendimento Documentar todo entendimento e cobrar aprovação do Cliente processo muito formal e muito trabalho adicional, para no final o cliente poder renegar até o que ele mesmo aprovou

8. Mudança é natural em projetos de software Mesmo que as regras estejam entendidas por todos, elas mudarão! Mudanças de regras podem salvar um negócio; As coisas precisam evoluir e software precisa seguir e se adaptar; A cada mudança, o que existia antes precisa continuar funcionando!

9. Uma boa ajuda, do pacote Agile Behaviour-DrivenDevelopment (BDD): Dan North, +- em 2003, pensando em uma forma de melhorar a legibilidade e utilidade de testes baseados em TDD; “Behaviour” is a more useful word than “test”

10. BDD, algumas características Test-first; Guiado pelo comportamento esperado; Foco no que deve ser feito, não em como será feito; Baseado na linguagem do negócio, não na linguagem técnica (Linguagem Onipresente); Maior colaboração entre equipe técnica e de negócio;

11. BDD, algumas vantagens Requisitos mais claros; Especificações executáveis com resultados legíveis para todos; Propagação da UbiquitousLanguage; Especificações servem como documentação (muito mais viva, que outras formas)

12. BDD, algumas desvantagens Foco no “o que” contribui pouco com o design interno; Mudanças no código devem ser refletidas nas especificações (quando não estão diretamente no código);

13. O Ciclo de Desenvolvimento, com BDD Basicamente o mesmo de TDD, trocando o “Teste” por “Especificação”

14. BDD versus TDD TDD é mais íntimo da implementação/design enquanto BDD está preocupado com o comportamento; BDD utiliza linguagem comum a várias audiências enquanto TDD é expressivo apenas para desenvolvedores;

15. BDD versus TDD Com TDD: Test Code (ao longo das mudanças). Essa relação pode ser menor com BDD; Apesar relacionadas, não são excludentes; Podem ser perfeitamente complementares;

16. BDD versus TDD jbehave.org/philosophy: These two practices are equally important but address different concerns and should be complementary in best development practices. BDD should talk the language of the business domain and not the language of the development technology, which on the other hand is “spoken” by TDD. BDD : (…) concerned primarily with the specification of the behaviour of the system under test as a whole (…) TDD: (…) concerned primarily with the testing of a component as a unit (…)

17. BDD + TDD BDD TDD http://msdn.microsoft.com/en-us/magazine/gg490346.aspx

18. BDD + TDD, a pirâmide dos testes Testing Pyramid for Web Apps, by Jason Huggins (inventor of Selenium) and Mike Cohn

19. BDD + DDD Dan North, em: http://www.infoq.com/presentations/bdd-and-ddd

20. BDD + DDD “DDD enables the use of BDD effectively creating software and BDD helps structure the conversations for DDD.” Dan North, em: http://www.infoq.com/presentations/bdd-and-ddd

21. E surge o JBehave Criado pelo próprio North, em 2003; Foi reescrito na versão 2.0, com base em características do RSpec, usando Java 5 e JUnit 4; Atualmente na versão 3; Utiliza JUnit para rodar cenários escritos em texto puro, apresentando a barra verde e vermelha; Pode ser automatizado com Maven ou Ant;

22. JBehavephilosophy http://jbehave.org/philosophy/

23. Vocabulário Title (one line describing the story) Narrative: As a [role] I want [feature] So that [benefit] Acceptance Criteria: (presented as Scenarios) Scenario 1: Title Given [context] And [some more context]... When [event] Then [outcome] And [another outcome]... Scenario 2: ... Advantages of the “As a user, I want” user story template, by Mike Cohn Cenáriosdescrevendooscomportamentosesperados.

24. Um exemplo de cenário Story: Account Holder withdraws cash As an Account Holder I want to withdraw cash from an ATM So that I can get money when the bank is closed Scenario 1: Account has sufficient funds Given the account balance is 100 And the card is valid And the machine contains enough money When the Account Holder requests 20 Then the ATM should dispense 20 And the account balance should be 80 And the card should be returned Scenario 2: Account has insufficient funds Given the account balance is 10 And the card is valid And the machine contains enough money When the Account Holder requests 20 Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should be 20 And the card should be returned Scenario 3: Card has been disabled Given the card is disabled When the Account Holder requests 20 Then the ATM should retain the card And the ATM should say the card has been retained

25. Mas, não parece com um “Caso de Uso”? Sim, mas apenas se comparar com bons Casos de Uso... Por exemplo, seguindo as dicas de AlistairCockburn...

26. Como os cenários são executados? Utilização das palavras chave dos cenários em texto puro; Criação classes para mapear os passos (Steps); Criação de classes para rodar os cenários, chamando os steps necessários; OBS: Utilizando o Jbehave 2.5.9!

27. Palavras-chave dos cenários Scenario: Validar nova senha Given Um usuário de nome: <nome> e login: <login> e a senha: <senha> When verifico se a senha é segura Then Deve retornar a mensagem: <mensagem>

28. Lista de palavras-chave disponíveis Scenario Narrative InOrderTo AsA IWantTo GivenScenarios ExamplesTable ExamplesTableRow Given When Then And Pending NotPerformed Failed Ignorable DryRun

29. Criação de Steps (Jbehave 2.5.9) Classes que estendem “Steps” do JBehave; Utilizam métodos (como testes no Junit) com mapeamento de palavras chave; Contém asserção para confirmação do comportamento.

30. Criação de Steps (Jbehave 2.5.9)

31. Criação de runners para Cenários Estendem de JUnitScenario; Inicialização (que pode ser feito por uma superclasse, facilitando as coisas – Ver exemplo com utilizaçao do PtBR); Adição dos Steps que serão executados;

32. Criação dos Cenários

33. Executando um cenário Mesma forma que um JUnittest; Resultados apresentados com barra verde e vermelha; Descrição de execução no console; Texto do console pode ser utilizado como “extrato da execução” dos testes;

34. Resultado da execução do cenário (step não implementado)

35. Resultado da execução do cenário (sucesso)

36. Resultado da execução do cenário (falha)

37. Utilização de Tabela de Exemplos Simplifica a criação de cenários; Permite criar um único cenário e definir diversas linhas com entradas e saídas esperadas no teste do comportamento; São executados testes para cada linha da tabela de exemplo, independentemente; Várias linhas e colunas separadas por “|” (no início e fim da coluna);

38. Tabela de Exemplos - Sintaxe TitleRecadastramento de Senha Narrative: As a Usuario I wantrecadastrar minha senha Sothat continue tendo acesso ao sistema, com outra senha Scenario: Validar nova senha GivenUm usuário de nome: <nome> e login: <login> e a senha: <senha> Whenverifico se a senha é segura ThenDeve retornar a mensagem: <mensagem> Examples: |nome|login|senha|mensagem| |Marcelo Zeferino|zeferino|1234|A senha deve conter ao menos 5 caracteres.| |Kurt Cobain|kurt|12345| | UserStory Definição do Cenário Tabela de Exemplos

39. Resultado de Execução com Tabela de Exemplos

40. Tudo bem, mas... Inglês e Português ao mesmo tempo ?! TitleRecadastramento de Senha Narrative: As a Usuario I wantrecadastrar minha senha Sothatcontinue tendo acesso ao sistema, com outra senha Scenario: Validar nova senha GivenUm usuário de nome: <nome> e login: <login> e a senha: <senha> Whenverifico se a senha é segura ThenDeve retornar a mensagem: <mensagem> Examples: |nome|login|senha|mensagem| |Marcelo Zeferino|zeferino|1234|A senha deve conter ao menos 5 caracteres.| |Kurt Cobain|kurt|12345| |

41. Configuração de Linguagem É possível configurar para que as palavras-chaves sejam traduzidas; Todas palavras precisam ser mapeadas para novo dialeto; Steps e Cenários precisam ser inicializados com o novo Locale e configuração;

42. Mapeamento de palavras-chave Scenario=Cenário: Narrative=Narrativa: InOrderTo=Para que AsA=Como um IWantTo=Eu desejo GivenScenarios=DadoCenários: ExamplesTable=Exemplos: ExamplesTableRow=LinhaTabelaExemplo: Given=Dado When=Quando Then=Então And="E" Pending=PENDENTE NotPerformed=Não Executado Failed=FALHA Ignorable=Ignorável DryRun=DryRun keywords_pt.properties

43. Configuração de classe Step

44. Novos Steps herdam de StepsPtBR

45. Configuração de classe Cenário

46. Novos cenários herdam de ScenarioPtBR Bem menores que antes, já que a inicialização está na SuperClasse:

47. Cuidados especiais com os keywords As frases dos cenários sofrem um parse para fazer os mapeamentos; Given->Dado; When ->Quando; Then -> Então; And -> E --- Ops,”E” é muito comum nos cenários quando ocorre o parse pode ser identificado e mapeado como “And”, gerando erro;

48. Solução Utilizar tradução de keywords com aspas (...) Then=Então And="E" Pending=PENDENTE (...)

49. Agora o output é em português

50. Considerações finais Há um trabalho inicial de setup do framework (como todos); As novas versões têm mudado a forma de utilizar o framework (como Scenarios -> Story, na mudança de 2.x para 3.0); Utilizar cenários para definir as conversas sobre os requisitos é muito útil; BDD e JBehave podem ser utilizados com TDD e JUnit sem problemas (se complementam, como sugerido por Dan North);

51. Dúvidas, Dívidas, Sugestões?

52. Links http://behaviour-driven.org/ http://dannorth.net/; http://jbehave.org/; http://jbehave.org/reference/stable/migration-paths.html; https://github.com/jbehave; http://www.infoq.com/presentations/bdd-and-ddd;

53. Contato marceloczeferino@gmail.com; http://continuepensando.wordpress.com/; http://www.linkedin.com/in/marcelozeferino; http://twitter.com/marcelozeferino; https://github.com/marcelozeferino;