BDD – Behavior Driven Development

Durante a Mesa Redonda do DFTestes sobre “Implementar BDD ou ATDD é possível na realidade?“, percebi que BDD e ATDD são duas siglas pouco conhecidas pela comunidade de Teste de Software brasileira. Portanto, acabei decidindo fazer dois posts para explicar o básico de cada técnica. 🙂

Neste primeiro irei falar sobre BDD, cuja tradução é: Desenvolvimento Direcionado por Comportamento.

Como disse no começo, ambos são técnicas e técnicas para a equipe de desenvolvimento de software, não de teste. Acredito que esse seja o motivo principal, do desconhecimento por parte do pessoal da área de Teste de Software dessas duas técnicas. Porém, é altamente recomendável o pessoal de teste também ter conhecimento sobre elas, uma vez que eles podem ajudar os desenvolvedores na implementação de tais técnicas,.

Mas antes de detalhar e dá algumas opiniões sobre BDD, vou contar um pouco de história.

Surgimento do BDD

Num certo dia, um tal de Dan North estava refletindo sobre as dificuldades dos programadores ao usar TDD:

  • Saber por onde começar;
  • O que testar e o que não testar;
  • Até onde testar;
  • Como chamar os testes;
  • E entender porque um teste falha.

E essas dúvidas e mal entendimentos eram observados com uma certa frequência pelo nosso amigo Dan North.

Foi aí que o Dan North viu a necessidade de criar algo para apresentar TDD de uma maneira direta ao lado iluminado da força. Evitando todas as armadilhas que podem levar o jovem aprendiz a ser tentado pelo lado negro da força.

Dan North então respondeu essa necessidade com a criação do BDD, que possui três princípios básicos:

  • Tudo é comportamento: A área de negócios e a de Tecnologia devem se referir para o sistema da mesma forma;
  • Onde está o valor do negócio: Todo sistema deve ter comportamentos que sejam um verificador do valor para o negócio;
  • Faça o suficiente: Analisar, projetar e planejar tudo de cima para baixo, evitando o detalhamento prematuro.

O BDD evoluiu a partir de práticas ágeis e foi desenvolvida para tornar elas mais acessíveis e eficazes para os times que estão iniciando a entregar software de forma ágil. Com o tempo, o BDD cresceu para abranger também a análise ágil e a automação dos testes de aceitação.

Mas afinal o que é BDD?

Em poucas palavras, o BDD é uma técnica de desenvolvimento de software, onde os programadores desenvolvem o software direcionados por comportamentos. Tais comportamentos são a nível de negócio e ajudam o programador a entender melhor a funcionalidade que será desenvolvida.

Além disso, várias ferramentas (ex.: JBehave e Cucumber) permitem ao programador transformar esses comportamentos em verificações automatizadas.

Melhorando a comunicação

A técnica de BDD confia no uso de um vocabulário bem específico e pequeno, com o objetivo de minimizar a falta de comunicação e garantir que TODOS (stakeholders, desenvolvedores, testadores, analistas e gerentes), não estão apenas na mesma página, mas também estão usando as mesmas palavras. BDD pode ser considerada uma Ubiquitous Language (“Linguagem Onipresente”).

Essa é a grande sacada do BDD, pois permite que todos os envolvidos no projeto possam utilizar da mesma fonte, os comportamentos, para a partir deles realizar o seu trabalho.

Comportamento?

Um comportamento é descrito através de uma história, cujo modelo é:

Como um [X]
Eu quero [Y]
Então [Z]

Onde:

  • X- é a pessoa que será beneficiada;
  • Y- é alguma funcionalidade
  • Z- é o benefício ou valor da funcionalidade;

Esse é um modelo que foi criado pelo Dan e pelo Chris Stevenson. E foi evoluído por eles para algo mais flexível para não ser artificial ou restrito aos analistas e estruturado o bastante para que as histórias possam ser quebradas e possam ser automatizadas. E aí a seguinte forma foi definida para definir um cenário, que está associado a uma história:

Dado algum contexto inicial (entradas),
Quando um evento ocorre,
Então verifique alguns resultados.

hmmm… isso me parece com algo

Sim, se parece com um caso de teste não é?

Entradas, ações e resultado esperado. Essa é a estrutura básica de um caso de teste, e é também a do cenário, proposta pelo BDD. A diferença está nas palavras e forma descrita, afinal é bom lembrar que um caso de teste nem sempre é algo tão entendível para os clientes.

BDD na prática

Eu já utilizei um pouco o BDD usando o Cucumber. E para fechar o post deixo um exemplo de implementação do BDD com o Cucumber, mais a título de exemplo mesmo (não irei explicar como instalar, implementar as steps definitions, executar, etc quem sabe num próximo post). Acredito que com ele fique mais fácil para encaixar as ideias e conceitos apresentados anteriormente.

No Cucumber temos a seguinte nomenclatura básica:

  • Funcionalidade: igual ao modelo de história elaborado pelo Dan e Steve;
  • Cenário: igual ao cenário explicado anteriormente.

Um exemplo de fluxo de BDD seria: cliente defini a funcionalidade e cenários associados a ela > desenvolvedor entender a funcionalidade e cenários e implementar as steps definitions > desenvolvedor roda um comportamento, irá falhar > desenvolvedor implementar o código para o comportamento > desenvolvedor executa o comportamento, que deverá funcionar.

Lembrando que esse é apenas um exemplo de fluxo de BDD, a forma de implementação e pessoas envolvidas pode variar de empresa para empresa, mas o fluxo básico acaba sendo esse mesmo (elaborar e rodar o comportamento, que irá falhar > desenvolver o código para o comportamento > executar o comportamento, que deverá passar), ou seja, igual ao do TDD.

Abaixo um exemplo, mostrando uma funcionalidade e cenários associados a essa funcionalidade:


#language: pt

Funcionalidade: Gerenciar produtos
    Para gerenciar produtos
    Como um usuário
    Eu quero criar, editar, apagar e visualizar produtos

    Cenário: Visualizar os produtos
        Dado eu tenho os produtos iPad, iPhone
        Quando eu vou para lista de produtos
        Então eu devo ver "iPad"
        E eu devo ver "iPhone"
    Cenário: Criar um produto
        Dado eu não tenho produtos cadastrados
        E que eu esteja na lista de produtos
        Quando eu clico "New"
        E eu preencho "Name" com "iPad"
        E eu preencho "Price" com "499"
        E eu aperto "Create"
        Então eu devo ver "Product was successfully created."
        E eu devo ver "iPad"
    Cenário: Editar um produto
        Dado eu tenho o produto iPad
        E que eu esteja na lista de produtos
        Quando eu clico "Edit"
        E eu preencho "Name" com "iPhone"
        E eu preencho "Price" com "199"
        E eu aperto "Update"
        Então eu devo ver "Product was successfully updated"
        E eu devo ver "iPhone"
    Cenário: Apagar um produto
        Dado eu tenho os produtos iPad, iPhone
        E que eu esteja na lista de produtos
        Quando eu clico "Destroy"
        Então eu não devo ver "iPad"
        E eu devo ver "iPhone"

Saiba mais:

Alguns bons artigos em português:

Tradução do Danilo Sato do artigo original do Dan North.

Introduzindo Desenvolvimento Orientado por Comportamento (BDD)

Artigo do Ronaldo Melo Ferraz, onde ele faz algumas considerações sobre TDD e BDD.

Algumas considerações sobre TDD e BDD

Artigo do Urubatan, mostrando algumas diferenças entre TDD e BDD e também o Cucumber.

Cucumber e BDD – Vantagens para a empresa (Argumentos para o gerente, para o arquiteto, para o presidente da empresa, …)

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://behaviour-driven.org/

http://blog.dannorth.net/introducing-bdd/

O modelo deveria ser flexível o suficiente para não parecer artificial ou restritivo para os analistas, porém estruturado o suficiente para que pudéssemos quebrar as histórias em pedaços que pudessem ser automatizados. Nós começamos a descrever os critérios de aceitação com base nos cenários, da seguinte fo
Anúncios

6º Encontro do Guru-SP – Eu fui!

Em pleno sabadão, num dia lindo acordo antes das 07:00, e não é para ir para a praia ou coisa do tipo, e sim para ir ao 6º Encontro do Guru-SP. 😀

Mas que “diacho” de encontro é esse Fabrício? Você foi consultar um guru espiritual?

Guru Ram Das, o 4º Guru da religião Sikh

Não, não (rsrs). O Guru-SP é esse daqui:

GURU SP

Hmmm… agora entendi. Mas o que você foi fazer num encontro de usuários de Ruby? Você programa em Ruby?

Não (mas depois de hoje fiquei com mais vontade ainda de aprender).

Um dos motivos para ter ido ao encontro foi o tema “Testes Automatizados” dele. Não tem jeito, colocar a palavra “teste” no tema de um evento, é mais efetivo do que falar que vai ter coffee break, para me fazer participar.

rsrs… que atitude nerd, perder um dia lindo desse, para ir num evento só por causa que vai falar sobre testes.

Que isso, olha o preconceito. Não é todo dia que você tem a oportunidade de participar de um evento sobre testes, onde que ia falar não atua na área de Teste de Software ou QA, e sim o pessoal do “lado negro da força” (“brincadeira minha, não é falando mal!”).

Interessante mesmo! Quem organizou o evento?

O 6º Encontro do Guro-SP foi organizado pelo Rafael Rosa, com o apoio da GoNow (local do encontro), Voice Technology (empresa na qual trabalho), O’Reilly e Ruby Inside Brasil, além é claro do Grupo de Usuário Ruby de SP.

E como foi o formato do encontro?

Foi no formato de mesa redonda (muito bom!), o pessoal da mesa ia falando sobre vários temas, que foram votados antes pelo pessoal que participou do encontro. Os debatedores foram:

  • Anderson Leite
  • Cássio Marques
  • Diego Carrion (não pode comparecer)
  • Fabio Kung (não pode comparecer)
  • Jorge Diz (o Jorge será o palestrante do 6º Encontro Mensal da ALATS-SP, a ser realizado nessa quarta-feira)
  • Ricardo Yasuda
  • Thiago Scalone

E o encontro foi dividido em duas partes, a primeira estimado das 10:00 ao 12:00 e a segunda das 12:30 às 15:00.

Da hora, a primeira parte como foi?

Ela começou com quase uma hora de atraso, com o Rafael Rosa falando sobre o encontro e como seria feito esse. Logo após, o pessoal já começou a “descer a lenha” falando sobre “Por que testar”, e pude perceber que a galera é bem comprometida como a realização dos testes, eles levam a sério mesmo e entendem as razões de porque testar.

Os debatedores também contaram experiências que tiveram fazendo BDD com o Cucumber e realizando testes de interface com o Selenium, por exemplo. Esse foi um ponto muito positivo do evento, ficou claro que os debatedores fazem o que eles falam, e puderam compartilhar experiências bem interessantes com o público. E a interação do público foi muito boa também, várias pessoas contaram os cenários que vivem, e também algumas dificuldades que tem em realizar os testes:

  • Tempo: projetos com prazos para ontem. Na minha opinião, realizar testes, principalmente na fase de desenvolvimento é uma prática que gera efeitos não tão bons a curto prazo, mas que a médio e longo prazo, se mostra essencial! Porém, como vivemos numa geração imediatista, muitas vezes as pessoas tem dificuldade em entender isso.
  • Complexidade: a criação de testes em sistemas complexos é um desafio maior ainda, às vezes pode ser mais difícil do que a própria implementação.
  • Sistemas legados: se dá uma manutenção em um sistema legado já é uma missão de embrulhar o estômago, imagine só criar testes para ele. Uma solução legal, comentada pelo pessoal e colocada em prática é realizar testes em nível de sistema, utilizando o Selenium por exemplo.

O Jorge Diz lembrou que a área de Teste de Software, costuma vir no reboque quando se usa metodologias frágeis (tradicionais). Mas usando metodologias ágeis o Teste de Software é incentivado, as novas técnicas já trazem na sua essência o pensamento de testar. Aliás, um exemplo disso é o uso de programação em par, onde uma pessoa já está revisando o código (lembrando que revisar é uma forma de testar).

Sobre o uso de BDD e TDD, o Anderson Leite disse que antes de partir para o uso delas, as pessoas precisam primeiro adquirir o hábito e prática de testar, só depois que já tiverem maduras podem começar a usar o BDD e TDD.

O Cássio Marques contou um pouco da sua experiência com linguagens de comparação, comparando no quesito de facilidade de testar. E disse que escrever testes em C e C++ é bem difícil, em Java também é meio enrolado. Já em Ruby é bem mais fácil. Podemos dizer que Ruby tem uma melhor “testabilidade”, que as outras, ou seja, se você é desenvolvedor Ruby e não testa, então você tem uma desculpa a menos para usar. 🙂

Um ponto importante discutido foi que se você testa, você não pode se dar ao luxo de deixar de testar uma funcionalidade, pois poderá resultar na velha história da janela quebrada.

Para terminar a primeira parte, houve uma demonstração do uso do Cucumber pelo Anderson. A minha primeira impressão foi que pareceu mágica o que ele fez (rsrs), ele escreveu os testes usando TDD e gerou o código usando o Scaffold de um cadastro de participante que tinha os campos nome e e-mail. Achei bem legal a demonstração, o Cucumber é uma ferramenta muito legal, nela você cria o teste como se estivesse criando uma caso de teste, segue abaixo um exemplo:

Exemplo de teste feito para o Cucumber

O Cucumber utiliza por default o Webrat, porém também é possível realizar o teste usando o Selenium RC, basta passar como parâmetro. O interessante do uso do Webrat é que diferente do Selenium, ele simula o navegador, rodando em background, ou seja, é muito mais rápido que o Selenium RC, porém tem a limitação de não conseguir testar javascript.

E depois do “rango”,  a segunda parte foi no mesmo nível que a primeira?

Depois do excelente coffee break, o Jorge Diz passou vários slides explicando a teoria de testes, abordando desde as escolas de teste até sobre os tipos de dublês. Essa parte fugiu um pouco do formato de debate, mas logo o Rafael Rosa retomou o formato, estimulando uma discussão sobre mocks e o perigo de “engessar muito” utilizando eles.

Do debate sobre mocks, o pessoal chegou a seguintes conclusões:

  • Se você está “mockando” muito, pode ser um sinal que a sua classe está fazendo mais do que ela deveria fazer. Então REFATORE;
  • Sempre tente modularizar ao máximo a sua aplicação, nada de ter uma classe “sistema”;
  • Os dublês em geral, devem ser usados sempre para resolver uma dependência.

Um assunto interessante abordado na apresentação do Jorge, foi como deve ser a pirâmide dos testes, de acordo com o nível:

TestingPyramidMas o que ocorre, geralmente, sem essa cultura de que desenvolvedor também testar, é uma inversão dessa pirâmide, ou seja, não há quase nenhum teste de unidade e integrado realizado, e muitos testes de sistema feitos pelo pessoal de Teste de Software.

E ainda houve mais duas práticas, uma com o Thiago Scalone mostrando o Selenium IDE e o RC. E depois mais uma com o Anderson apresentando o RSpec (o JUnit do Ruby)

E o que você achou? Pelo jeito deve ter sido ótimo, afinal além de falar de testes deve coffee break na faixa.

Excelente encontro! Comprovou que é mito essa história que desenvolvedor não testa, eles testam sim, e até melhor do que muito testador que tem por aí. E Ruby é uma linguagem que oferece uma “testabilidade” incrível, as ferramentas que existem são muito boas, e ajudam desde o teste de nível unitário até o teste de nível de aceite. E essa brincadeira que faço sobre “lado negro da força”, em breve ficará sem sentido, pois os testes estão se tornando cada vez mais uma tarefa inerente ao desenvolvimento.

Para encerrar o post, parabéns a todos que participaram, e principalmente, ao Rafael Rosa, pela excelente organização!

Para saber mais sobre o 6ºEncontro acesse a wiki do Guru-SP:

http://guru-sp.com/index.php/Sexto_Encontro

E para saber sobre os próximos encontros acompanhe o Ruby Inside Brasil:

http://www.rubyinside.com.br/

Fique por dentro das novidades, assine o feed do QualidadeBR.

guru espiritual