RioJUG, reunião de Janeiro/2011

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 School of 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.

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;

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!

Cliente: Argh, não foi isso que eu pedi! Você: Mas foi o que lhe passei e você

aprovou!

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

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!

Behaviour-Driven Development (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”

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;

Requisitos mais claros; Especificações executáveis com resultados

legíveis para todos; Propagação da Ubiquitous Language; Especificações servem como documentação

(muito mais viva, que outras formas)

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);

Basicamente o mesmo de TDD, trocando o “Teste” por “Especificação”

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;

Com TDD: TestCode (ao longo das mudanças). Essa relação pode ser menor com BDD;

Apesar relacionadas, não são excludentes; Podem ser perfeitamente complementares;

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 domainand 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 (…)

http://msdn.microsoft.com/en-us/magazine/gg490346.aspx

BDD TDD

Testing Pyramid for Web Apps, by Jason Huggins (inventor of Selenium) and Mike Cohn

Dan North, em: http://www.infoq.com/presentations/bdd-and-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

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;

http://jbehave.org/philosophy/

Title (one line describing the story)

Narrative:As a [role]I want [feature]So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: TitleGiven [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ários descrevendo oscomportamentos esperados.

Story: Account Holder withdraws cash

As an Account HolderI want to withdraw cash from an ATMSo that I can get money when the bank is closed

Scenario 1: Account has sufficient fundsGiven the account balance is \$100And the card is validAnd the machine contains enough moneyWhen the Account Holder requests \$20Then the ATM should dispense \$20And the account balance should be \$80And the card should be returned

Scenario 2: Account has insufficient fundsGiven the account balance is \$10And the card is validAnd the machine contains enough moneyWhen the Account Holder requests \$20Then the ATM should not dispense any moneyAnd the ATM should say there are insufficient fundsAnd the account balance should be \$20And the card should be returned

Scenario 3: Card has been disabledGiven the card is disabledWhen the Account Holder requests \$20Then the ATM should retain the cardAnd the ATM should say the card has been retained

Sim, mas apenas se comparar com bons Casos de Uso...

Por exemplo, seguindo as dicas de AlistairCockburn...

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!

Scenario: Validar nova senhaGiven Um usuário de nome: <nome> e login: <login> e a senha: <senha>When verifico se a senha é seguraThen Deve retornar a mensagem: <mensagem>

Scenario Narrative InOrderTo AsA IWantTo GivenScenarios ExamplesTable ExamplesTableRow Given

When Then And Pending NotPerformed Failed Ignorable DryRun

1. Classes que estendem “Steps” do JBehave;2. Utilizam métodos (como testes no Junit)

com mapeamento de palavras chave;3. Contém asserção para confirmação do

comportamento.

1. Estendem de JUnitScenario;2. Inicialização (que pode ser feito por uma

superclasse, facilitando as coisas – Ver exemplo com utilizaçao do PtBR);

3. Adição dos Steps que serão executados;

Mesma forma que um JUnit test; 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;

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);

Title Recadastramento de SenhaNarrative:As a UsuarioI want recadastrar minha senhaSo that continue tendo acesso ao sistema, com outra senha

Scenario: Validar nova senhaGiven Um usuário de nome: <nome> e login: <login> e a senha: <senha>When verifico se a senha é seguraThen Deve 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| |

User Story

Definição do Cenário

Tabela de Exemplos

Title Recadastramento de SenhaNarrative:As a UsuarioI want recadastrar minha senhaSo that continue tendo acesso ao sistema, com outra senha

Scenario: Validar nova senhaGiven Um usuário de nome: <nome> e login: <login> e a senha: <senha>When verifico se a senha é seguraThen Deve 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| |

Inglês e Português ao mesmo tempo ?!

É 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;

Scenario=Cenário:Narrative=Narrativa:InOrderTo=Para queAsA=Como umIWantTo=Eu desejoGivenScenarios=DadoCenários:ExamplesTable=Exemplos:ExamplesTableRow=LinhaTabelaExemplo:Given=DadoWhen=QuandoThen=EntãoAnd="E"Pending=PENDENTENotPerformed=Não ExecutadoFailed=FALHAIgnorable=IgnorávelDryRun=DryRun

keywords_pt.properties

Bem menores que antes, já que a inicialização está na SuperClasse:

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;

Utilizar tradução de keywords com aspas

(...)Then=Então

And="E"Pending=PENDENTE(...)

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);

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;

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