: : : :

Transcrição

1 : : : : Marcelo Zeferino (marceloczeferino@gmail.com): formado em análise de sistemas, atua com TI desde 1999 e já participou de projetos de software 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. Mantem o blog com ideias sobre desenvolvimento de software. 30

2 As práticas de teste antecipado têm ganhado cada vez mais adeptos nos últimos anos com a crescente utilização de Test-Driven Development (TDD), sendo encorajada pelo extreme Programming e outros métodos ágeis. Como evolução ao TDD, Behaviour-Driven Development (BDD) nos permite criar, junto aos clientes, especificações que poderão ser executadas (e automatizadas), utilizando textos simples, em linguagem natural. Neste artigo, será apresentado o framework JBehave e trabalharemos um exemplo prático de especificação de cenário. Ao final, iremos configurar a ferramenta para utilizar o português como língua padrão nas especificações, facilitando ainda mais a compreensão. Behaviour-Driven Development em Java na prática, com JBehave Criando especificações executáveis utilizando BDD, em nossa língua! magine o seguinte problema: precisamos desenvolver um módulo de nossa aplicação que possui regras de negócio complicadas que estão apenas na cabeça de nosso cliente ou em um daqueles bons e velhos documentos estáticos e, provavelmente, desatualizados. Começamos entendendo e documentando as regras, modelando etc., até que arregaçamos as mangas e vamos para o desenvolvimento. Ao longo do desenvolvimento vamos criando testes e codificando, seguindo os ciclos do TDD. Após algumas repetições, executamos nossa suíte de teste e temos a certeza de que está tudo funcionando, até que o cliente verifica o funcionamento e nos informa que desenvolvemos a funcionalidade baseados em regras que na realidade estavam erradas (aquela velha história do não foi bem isso o que quis dizer ). Agora, digamos que, ao invés da abordagem anterior, escrevemos especificações junto à área cliente/de negócio, em nossa própria língua, a partir das necessidades relatadas para aquela funcionalidade, com exemplos de valores de entrada e saída de sucesso e falha para a execução de nosso módulo, mapeando e nos guiando pelo comportamento esperado. Passamos pelo ciclo de desenvolvimento 31

3 : : : : (executando testes aos poucos) e, ao final, executamos a nossa especificação (que foi escrita em texto puro) tendo como feedback as falhas e sucessos de acordo com os valores que especificamos. Isso mesmo, estamos falando de algo como uma especificação executável! Com a segunda abordagem, temos algumas vantagens: participação mais ativa do cliente; nosso código não está diretamente acoplado aos testes (o que acontece bastante com TDD) e está mais íntimo ao comportamento final; ao invés de testes escritos em Java, temos especificações em texto puro e em nossa língua que servirão como documentação da funcionalidade, facilitando o entendimento das necessidades e expectativas. Estas são apenas algumas vantagens do BDD. Ao longo deste artigo, será apresentado um pouco do conceito por trás do BDD e utilizaremos um exemplo prático, com o JBehave, para nos auxiliar neste processo. Ao final, será apresentado como podemos estender a ferramenta para que possamos escrever nossas especificações em português, facilitando ainda mais o entendimento. Primeiramente, um pouco de conceito O BDD segue a mesma linha de pensamento de outros métodos baseados em test-first, em que iniciamos o desenvolvimento de uma funcionalidade com escrita de testes antes de escrevermos qualquer linha de código de produção e, como sugere o TDD, seguimos ciclos de 1) criação de um teste que falhe; 2) implementação de código que faça o teste passar (e nada além disso); e 3) refatoração do código criado no passo anterior visando melhorá-lo. Dessa forma, além de termos a garantia de testes automatizados (já que os criamos antes mesmo de criar código de produção), não cairemos na velha armadilha de deixar os testes para depois, quando tivermos mais folga no cronograma geralmente, nunca! Apesar de apresentar grandes vantagens, principalmente no design, TDD possui algumas desvantagens, como o forte acoplamento entre testes e classes e baixa expressividade do código de testes, tendo em vista que, mesmo utilizando padrões na escrita dos métodos de teste, ainda estamos falando de código Java. Por mais expressivo que este seja, ainda será código em uma linguagem de programação, o que é algo geralmente distante de pessoas mais voltadas para o negócio. Neste contexto, a principal ideia do BDD é facilitar a comunicação sobre os requisitos entre pessoas de negócio (analistas de negócio, patrocinadores etc.) e o time de desenvolvimento. Apesar de dar ênfase na comunicação, também é esperado que os comportamentos/requerimentos levantados nestas comunicações possam ser verificados de forma automática (inclusive com integração contínua). A ideia é que o desenvolvimento seja guiado através do comportamento esperado para a funcionalidade, encorajando os envolvidos a trabalharem juntos na definição de especificações que poderão ser executadas automaticamente, comprovando o funcionamento conforme o que foi definido. Segundo texto publicado em seu blog, Dan North iniciou em 2003 o desenvolvimento do primeiro framework para trabalho com BDD: o JBehave. A intenção era sobrescrever o JUnit fazendo com que referências a teste fossem substituídas por comportamento. Seguindo 32 este raciocínio, são desenvolvidos cenários como o apresentado na Listagem 1 (retirado do site do projeto JBehave). Listagem 1. Exemplo básico de cenário. Given I am not logged in When I log in as Liz with a password JBehaver Then I should see a message, Welcome, Liz! A partir daí, o JBehave utiliza classes Java para mapear os fragmentos dos cenários, fazendo o parse das informações e executando os testes no formato JUnit, com exibição de resultados aproveitando a estrutura disponibilizada por ele. O relacionamento entre BDD e Domain-Driven Design (DDD) Mais ou menos na mesma época, Eric Evans publicou seu livro Domain-Driven Design: Tackling Complexity in the Heart of Software que falava sobre o desenvolvimento de softwares tomando como base os conceitos envolvidos no domínio do negócio, fazendo com que seja utilizada uma linguagem única (ubíqua), melhorando a comunicação entre a equipe técnica e de negócio. Neste sentido, BDD torna-se ainda mais útil sendo utilizado na análise do problema, identificando cenários e critérios de aceitação com user stories que serão executadas (com o JBehave, por exemplo) para validar o funcionamento. A aproximação entre equipe técnica e de negócio, utilizando uma linguagem única que é perfeitamente entendida pelos dois grupos, conforme pregou Evans, ganha mais força quando os dois grupos podem trabalhar juntos na elaboração de especificações funcionais baseadas em pequenas especificações executáveis. BDD vs TDD Em alguns momentos pode parecer que há algum tipo de disputa ou concorrência entre BDD e TDD, mas é importante entender que as duas metodologias possuem focos de atuação diferentes e podem ser utilizadas de forma complementar. Na edição 43 da MundoJ, há um artigo do Rodrigo Yoshima com mais informações sobre TDD e BDD, suas origens e o relacionamento entre estas duas abordagens. No site do JBehave, podemos encontrar uma breve comparação entre as duas metodologias que é bastante interessante e traduzi livremente aqui (o quadro de referências no final do artigo contém o link para o texto original): É importante entender a diferença entre BDD e TDD. Essas duas práticas são igualmente importantes, mas possuem focos diferentes e devem ser complementares no uso das melhores práticas de desenvolvimento. BDD está preocupado principalmente com a especificação do comportamento do sistema sendo testado como um todo, portanto, é particularmente adequado para testes de aceitação e regressão. TDD está preocupado principalmente com o teste de um componente como unidade, mantendo-o isolado de outras dependências, que normalmente são "mockadas". BDD deve falar a linguagem do domínio de negócio e não a linguagem da tecnologia do desenvolvimento, que, por outro lado, é "falada" pelo TDD.

4 A criação e evolução do JBehave Como já falamos e segundo o blog do próprio Dan North (vide quadro de referências), o JBehave foi iniciado em 2003 e no começo algumas coisas não saíram muito bem. A maioria das características que o faz uma boa escolha hoje em dia foram baseadas em outros frameworks, particularmente o RSpec. Para mais informações, os artigos Automação de Testes de Aceitação com Cucumber e JRuby, Ed. 39 e Aplicações Desktop a jato com JRuby e Netbeans, Ed. 36 abordaram a utilização de RSpec e Cucumber (ver quadro de referências, no final do artigo). A partir daí, ao longo dos anos, a ferramenta sofreu fortes modificações (North fala que foi completamente reescrito, em seu blog na nota de lançamento da versão 2.0), inclusive para tirar proveito das facilidades de Java 5 e JUnit 4. A versão 2.0 é considerada um marco, pois já disponibiliza algumas ótimas características como integração com Maven, cenários em texto puro, entre outras. a classe Steps) e outra para definir o cenário (estendendo a classe Scenario). A classe que representa o cenário será executada como um teste JUnit e apresentará os resultados com as famosas barras verdes ou vermelhas (como um JUnit Test mesmo). Para isso, esta classe precisa, em seu construtor, adicionar cada Step criado para o cenário. Outro ponto importante é que o nome da classe deve ter relacionamento direto com o nome do arquivo que contém a descrição do cenário. Exemplo: para um cenário user_logs_in_successfully a classe que o representará deve ser UserLogsInSuccessfully, trocando os _ por camel casing; Criando nosso primeiro exemplo Entendendo os cenários e vocabulário No exemplo que iremos criar, implementaremos parte de uma funcionalidade para alteração de senha de acesso ao sistema. Neste ponto faremos apenas uma rápida verificação para identificar se é ou não uma senha segura. O BDD possui um vocabulário próprio que tenta ser bastante simples para facilitar sua utilização como linguagem ubíqua e seus principais componentes são Given, When e Then. Após criar um projeto novo e configurar as dependências (ver seção Dependências Necessárias), criaremos o arquivo de texto validacao_nova_senha.scenario, com o conteúdo da Listagem 3. Colocando a mão na massa! Tendo User Stories definidas, podemos criar o que chamamos de cenários para representá-las, podendo definir diversos cenários para cada uma delas, garantindo que trabalhamos todas as variações que formam o critério de aceite da User Story. Seguindo o padrão de Stories As a <type of user>, I want..., sugerido por Mike Cohn em seu blog (ver quadro de referências), poderíamos ter uma story como a apresentada na Legenda 2 (retirada do blog de Dan North). Listagem 2. Exemplo de story seguindo o padrão de Mike Cohn. As a customer, I want to withdraw cash from an ATM, So that I don t have to wait in line at the bank. E um possível cenários seria: Scenario 1: Account is in credit Given the account is in credit And the card is valid And the dispenser contains cash When the customer requests cash Then ensure the account is debited And ensure cash is dispensed And ensure the card is returned Há os que defendam abordagens mais completas, mencionando critérios de aceite mais detalhados e tabelas de dados. Como os cenários serão executados? Os cenários são salvos em um arquivo-texto e, para cada cenário, precisaremos de uma classe Java que defina os passos (estendendo Dependências necessárias Para o funcionamento correto da versão (utilizada em nosso projeto) do framework, é necessário configurar as seguintes dependências no classpath do projeto: jbehave-core jar (download direto do site do JBehave: hamcrest-all-1.1.jar ( commons-lang-2.5.jar ( download_lang.cgi); commons-collections.jar Além do JUnit4 (em Listagem 3. Código do cenário Validação de Nova Senha. Title Recadastramento de Senha Narrative: As a Usuario I want recadastrar minha senha So that continue tenasso ao sistema, com outra senha Scenario: Validar nova senha Given Um usuário de nome Marcelo Zeferino e login zeferino e a senha é 1234 When verifico se a senha é segura Then Deve retornar a mensagem A senha deve conter ao menos 5 caracteres. Feito isso, temos nossa especificação pronta e precisamos criar uma classe que execute nosso cenário. Para tanto, criaremos a classe ValidacaoNovaSenha.java, seguindo as convenções do JBehave, com o conteúdo da Listagem 4. 33

5 : : : : Listagem 4. Implementação da classe responsável por rodar o cenário. Listagem 5. Implementação da classe responsável pelos passos de teste dos cenários. public class ValidacaoNovaSenha extends JUnitScenario { public class ValidacaoNovaSenhaSteps extends Steps { private Usuario usuario = new Usuario(); public ValidacaoNovaSenha() { private String mensagemerro; super(new MostUsefulConfiguration() usuário de nome $nomeusuario e login $loginusuario e a senha é $novasenha") public void setup(string nomeusuario, String loginusuario, String novasenha) { public ScenarioDefiner fordefiningscenarios() { return new ClasspathScenarioDefiner( new UnderscoredCamelCaseResolver(.scenario ), new PatternScenarioParser(keywords())); mensagemerro = ""; usuario.setnome(nomeusuario); usuario.setlogin(loginusuario); public ScenarioReporter forreportingscenarios() { return new se a senha é segura") public void checksenha() { ); try{ usuario.validarnovasenha(); catch (Exception e) { mensagemerro = e.getmessage(); Feito isso, já podemos executar nosso teste e verificar o resultado. Rodando a nossa classe como um JUnit Test temos o resultado apresentado na figura 1, mostrando que a implementação dos passos de nosso cenário ainda estão retornar a mensagem \"$mensagem\"") public void checkmessagem(string mensagem) { ensurethat(mensagemerro.equalsignorecase(mensagem)); O JBehave utiliza para codificar algum comportamento para cada um destes passos do cenário descrito no arquivo de texto. Figura 1. Execução com passos ainda pendentes. O próximo passo é criar a classe que implementará os passos necessários para testar nossa especificação. Criaremos uma classe chamada ValidacaoNovaSenhaSteps.java, estendendo a classe Steps do JBehave, com o conteúdo da Listagem Podemos utilizar o conteúdo do arquivo de texto e fazer parsing das Strings a fim de compará-las com os resultados esperados. No nosso caso, queremos comparar se o conteúdo da variável mensagemerro, que está sendo recuperado de acordo com a Exception lançada pelo método validarnovasenha da classe Usuário, é equivalente à mensagem apresentada na descrição do cenário. Poderíamos neste ponto validar diversas entradas e saídas, de acordo com nossas necessidades, não estando limitados a apenas tipos String. O conteúdo da classe Usuário.java está descrito na Listagem 6.

6 Listagem 6. Implementação da classe de negócio Usuário, com o comportamento para verificação da senha. Listagem 7. Alteração na classe ValidacaoNovaSenha para executar o TestStep criado. package main.java.usuario; public class ValidacaoNovaSenha extends JUnitScenario { public ValidacaoNovaSenha() { public class Usuario { super(new MostUsefulConfiguration() { public Usuario(){ private String nome; private String login; private String senha; public ScenarioDefiner fordefiningscenarios() { return new ClasspathScenarioDefiner( new UnderscoredCamelCaseResolver(".scenario"), new PatternScenarioParser(keywords())); public String getnome() { return nome; public void setnome(string nome) { this.nome = nome; public String getlogin() { return login; public void setlogin(string login) { this.login = login; public String getsenha() { return senha; public void setsenha(string senha) { this.senha = public ScenarioReporter forreportingscenarios() { return new PrintStreamScenarioReporter(); ); addsteps(new ValidacaoNovaSenhaSteps()); public void validarnovasenha() throws Exception{ if (this.getsenha().length() < 5){ throw new Exception("A senha deve conter ao menos 5 caracteres."); Neste ponto, estamos aptos para inserir nosso TestStep no construtor da classe ValidacaoNovaSenha.java para que o runner chame a classe ValidacaoNovaSenhaSteps.java e execute os passos que predefinimos. Figura 2. Resultado de execução com sucesso. Para isso, incluiremos a linha addsteps(new ValidacaoNovaSenhaSteps()); após a chamada a super na classe ValidacaoNovaSenha.java, para ficar da forma apresentada na Listagem 7 e executaremos novamente esta classe como um JUnitTest. Se tudo correr bem, o resultado será apresentado como na figura 2, apresentando o sucesso do teste. Para testar o caso de falha, podemos alterar a mensagem da especificação e rodar novamente, verificando que o JUnit irá apresentar a barra vermelha, indicando que ocorreu uma falha, como na figura 3. Figura 3. Falha na execução do teste, indicando que uma condição não foi satisfeita, após alterarmos a mensagem. 35

7 : : : : Criando cenários com Tabela de Dados de Exemplo Uma ótima opção para trabalhar com mais dados de entrada para os testes é a utilização do recurso Table Examples. Este recurso permite que seja definida uma tabela com valores de entrada e/ou saída para o(s) cenário(s) de uma especificação, sem a necessidade de criar diversos cenários (um para cada entrada de dados, por exemplo). A sintaxe para a criação de Table Examples é apresentada na Listagem 8, já com uma aplicação prática no nosso exemplo. Listagem 9. Alterações na classe ValidacaoNovaSenhaSteps. java para compatibilizar com a utilização da tabela de exemplos. public class ValidacaoNovaSenhaSteps extends Steps { private Usuario usuario = new Usuario(); private String usuário de nome: <nome> e login: <login> e a senha: <senha>") public void setup(@named("nome") String String String novasenha) { Note que retiramos os valores anteriormente passados manualmente para os passos e adicionamos <> nos campos nome, login, senha e mensagem para que estes dados sejam recuperados da tabela de exemplos, no final da story. mensagemerro = ""; usuario.setnome(nomeusuario); usuario.setlogin(loginusuario); usuario.setsenha(novasenha); Foi necessário, também, alterar a classe ValidacaoNovaSenhaSteps.java para que os passos do cenário considerem as alterações feitas na especificação. A Listagem 9 apresenta o código alterado desta classe, utilizando a NomeDoCampo ), para identificar os valores recebidos da se a senha é segura") public void checksenha() { Note que a utilização deste tipo de anotação é bastante útil, pois é possível utilizar diretamente os atributos com seus tipos reais, ao invés de trabalhar com o parsing de Strings. try{ usuario.validarnovasenha(); catch (Exception e) { mensagemerro = e.getmessage(); A figura 4 apresenta o log geral de execução das entradas na tabela de exemplos, impresso no console. Listagem 8. Alterações em nossa especificação para utilização de Table Examples. Title Recadastramento de Senha Narrative: As a Usuario I want recadastrar minha senha So that continue tendo acesso ao sistema, com outra retornar a mensagem: <mensagem>") public void checkmessagem(@named("mensagem") String mensagem) { ensurethat(mensagemerro.trim().equalsignorecase(mensagem)); Title Recadastramento de Senha Narrative: As a Usuario I want recadastrar minha senha So that continue tendo acesso ao sistema, com outra senha 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> Examples: nome login senha mensagem Marcelo Zeferino zeferino 1234 A senha deve conter ao menos 5 caracteres. Kurt Cobain kurt Figura 4. Console apresentando resultado de execução de especificação utilizando Table Examples. 36

8 Mas estamos escrevendo em inglês e português ao mesmo tempo! Neste ponto, criei uma nova classe genérica para os cenários e steps em português, fazendo com que as classes anteriores agora herdem destas novas classes. Estendendo o JBehave para utilizar Português-BR nos cenários As Listagens 11 e 12, respectivamente, apresentam o código das classes genéricas para os cenários e steps, incluindo alguns comentários relevantes. Agora que já passamos por alguns conceitos básicos sobre o framework, percebemos que a utilização de inglês (devido ao padrão Given, When, Then) e português no mesmo documento não soa muito bem. Inclusive, pode ser um empecilho para o objetivo de alcançar maior participação dos envolvidos. Listagem 11. Classe genérica, com configurações para utilizar língua personalizada pelo arquivo keywords_pt. public class ScenarioPtBR extends JUnitScenario { O JBehave nos reserva a possibilidade de estendê-lo para utilizar outros dialetos, permitindo configurar o vocabulário para a forma que melhor atenda aos usuários. Criaremos novas classes e especificação, agora utilizando apenas nossa linguagem na descrição das especificações. Manteremos a mesma funcionalidade para permitir um comparativo. public ScenarioPtBR() { this(thread.currentthread().getcontextclassloader()); public ScenarioPtBR(final ClassLoader classloader) { super(new PropertyBasedConfiguration() public ScenarioDefiner fordefiningscenarios() { Criando o arquivo de redefinição do vocabulário (keywords_ pt.properties) // Repare que aqui estamos utilizando a extensão.cenario e não //.scenario, como antes return new ClasspathScenarioDefiner( new UnderscoredCamelCaseResolver(".cenario"), new PatternScenarioParser(this), classloader); Para que o JBehave possa trabalhar com nosso vocabulário, precisamos definir um arquivo de palavras-chave, traduzindo tais palavras para o nosso idioma. A Listagem 10 apresenta o conteúdo deste arquivo (salvo como keywords_pt.properties). Listagem 10. Arquivo de mapeamento de palavras-chaves e suas traduções. 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\u00E3o Executado Failed=FALHA Ignorable=Ignoravel DryRun=DryRun Um alerta para a linha que contém o mapeamento do keyword And (ainda na Listagem 10). Neste caso, utilizamos E, entre aspas, devido a problemas na biblioteca utilizada pelo JBehave para fazer o match das strings. Caso não tivéssemos usado as aspas o And seria convertido para qualquer palavra que iniciasse com a letra E. Outra solução seria envolver todas as palavras em public ScenarioReporter forreportingscenarios() { //definição do Locale "pt", utilizado na exibição dos resultados return new PrintStreamScenarioReporter(keywordsFor( new Locale("pt"), classloader)); //Definição do Locale utilizado na obtenção dos public KeyWords keywords() { return keywordsfor(new Locale("pt"), classloader); ); //Aqui está sendo definido o pacote onde está inserido o arquivo properties com //mapeamento das palavras chaves traduzidas para o Português protected static KeyWords keywordsfor(locale locale, ClassLoader classloader) { return new I18nKeyWords(locale, new StringEncoder(), "test/resources/keywords", classloader); Além de criar o arquivo keywords_pt_properties da Listagem 10, precisaremos definir algumas configurações em nossas classes (tanto a que funciona como runner dos cenários quanto a que define o comportamento dos passos de execução) para que as novas configurações sejam utilizadas. 37

9 : : : : Listagem 12. Classe genérica para Steps com configurações para utilizar língua personalizada pelo arquivo keywords_pt. Cont. Listagem 14. Classe para execução dos steps, agora herdando comportamentos de configuração de linguagem. public class StepPtBR extends Steps { try{ usuario.validarnovasenha(); public StepPtBR(){ this(thread.currentthread().getcontextclassloader()); catch (Exception e) { mensagemerro = e.getmessage(); //Definindo que serão utilizados os keywords traduzidos public StepPtBR(ClassLoader classloader) { super(new StepsConfiguration(keywordsFor(new Locale("pt"), classloader))); //Aqui está sendo definido o pacote onde está inserido o arquivo properties com //mapeamento das palavras chaves traduzidas para o Português protected static KeyWords keywordsfor(locale locale, ClassLoader classloader) { return new I18nKeyWords(locale, new StringEncoder(), "test/resources/keywords", retornar a <mensagem>") public void checkmessagem(@named("mensagem") String mensagem) { ensurethat(mensagemerro.trim().equalsignorecase(mensagem)); Listagem 15. Especificação, agora escrita em nossa língua. Título Recadastramento de Senha As Listagens 13 e 14 apresentam o código das novas classes para runner de cenários e steps, que agora herdam as características de configuração das classes genéricas. Na Listagem 15, temos o novo texto de nossa especificação, agora em português. Listagem 13. Classe para execução do cenário, simplificada pela herança de comportamentos de configuração de linguagem. Narrativa: Como a Usuario Eu desejo recadastrar minha senha Para que continue tendo acesso ao sistema, com outra senha Cenário: Validar nova senha Dado Um usuário de <nome> e <login> e a <senha> Quando verifico se a senha é segura Então Deve retornar a <mensagem> public class ValidacaoNovaSenhaPtBr extends ScenarioPtBR { public ValidacaoNovaSenhaPtBr(){ addsteps(new ValidacaoNovaSenhaStepsPtBr()); Exemplos: nome login senha mensagem Marcelo Zeferino zeferino 1234 A senha deve conter ao menos 5 caracteres. Kurt Cobain kurt Por fim, a figura 5 contém o resultado da execução, já utilizando nossa língua e a figura 6 contém a estrutura final de nossa aplicação. Listagem 14. Classe para execução dos steps, agora herdando comportamentos de configuração de linguagem. public class ValidacaoNovaSenhaStepsPtBr extends StepPtBR { private Usuario usuario = new Usuario(); private String usuário de <nome> e <login> e a <senha>") public void setup(@named("nome") String String String novasenha) { mensagemerro = ""; usuario.setnome(nomeusuario); usuario.setlogin(loginusuario); se a senha é segura") public void checksenha() { 38 Figura 5. Console com a execução, após configuração da língua para português.

10 Utilizar uma prática baseada em TestFirst é importante para garantir que testes automatizados existirão (e não ficarão para quando a equipe tiver tempo nunca!) e que o design da aplicação será orientado para facilitar testes. Existem diversas ferramentas que habilitam a utilização de BDD em Java, como EasyB, JBee, EasySpec e o famoso Cucumber (com JRuby). No entanto, JBehave se posiciona no mercado como uma ótima opção e, em minha opinião, é a melhor dentre outros frameworks, pois podemos criar especificações de maneira bastante simples e utilizando puramente Java (e não JRuby ou Groovy, por exemplo, como no caso de Cucumber e EasyB, respectivamente). A ferramenta ainda permite uma série de outras habilidades não apresentadas neste artigo, como a integração com outros frameworks, como HTMLUnit e Selenium, por exemplo. É possível encontrar uma implementação de exemplo utilizando JBehave sobre WebDriver (HTMLUnit) no GitHub profile do Rodrigo Yoshima (da Aspercom e colunista da MundoJ), descrito na seção de referências no final do artigo. Outra capacidade interessante é a integração com Ant e Maven, facilitando a execução automática dos testes de acordo com o ponto no ciclo de vida da aplicação, mas este é um assunto para um novo artigo Figura 6. Estrutura final da aplicação, no Eclipse. Considerações finais São diversos os benefícios na utilização de BDD, como a possibilidade de escrever especificações junto aos usuários finais garantindo melhor entendimento do problema. Tais especificações servirão como documentação e poderão ser executadas automaticamente para validação e verificação dos cenários, o que aumenta consideravelmente a chance de se tornar uma documentação útil e constantemente atualizada. Referências blog de Dan North. post no blog de Dan North com detalhes sobre a evolução do JBehave e sua versão post no blog de Dan North sobre a filosofia do framework e breve, porém excelente e esclarecedora, comparação entre BDD e TDD. Automação de Testes de Aceitação com Cucumber e JRuby Ed 39 da MundoJ, Aplicações Desktop a jato com JRuby e Netbeans Ed 36 da MundoJ. site de referência para o RSpec. Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans. blog oficial do framework. link do GitHub profile de Rodrigo Yoshima, com exemplo prático utilizando JBehave sobre WebDriver. post em blog de Mike Cohn com template para User Stories. Para aplicações nas quais utilizamos Domain-Driven Design, a utilização de BDD aparece com grande utilidade, facilitando a criação e manutenção da Ubiquitous Language, entre desenvolvedores e pessoas de negócio. 39