BDD e Java: Behavior Driven Development com Cucumber

[00:00] Você tem interesse em saber o que é o BDD? Como esse Behavior Driven Development se encaixa no universo de teste e no processo ágil? Ou quais são as vantagens de usar e principalmente como usar?

[00:15] Você já ouviu falar de Cucumber ou Gherkin? Se sim ou não, não importa, você está no curso certo para aprender sobre essa ferramenta e como o BDD em geral se encaixa no mundo de ágil.

[00:34] Então além de entender e formalizar todo esse processo, nós vamos usar o Cucumber, e vamos usar o Selenium "por baixo dos panos" para criar especificações executáveis e colocar as especificações no nosso código para testar e transformar isso em código e testar através de vários passos, em uma aplicação real.

[01:02] Se você gostou da ideia, se você ficou interessado nesse tópico importante de BDD e quer começar a usar, fica comigo, você está no lugar certo. Até já!

[00:00] Oi, alunos e alunas. Vamos continuar nosso curso sobre BDD.

[00:05] E antes de começar a mexer no código, ver o ambiente, o código, o projeto e os testes que já existem, eu gostaria de dar uma pequena introdução: o que é e qual o problema que o BDD, o Behavior Driven Development quer resolver? Para cada solução, cada ferramenta, sempre existe um problema real por trás.

[00:33] Então qual é o nosso problema? Lembrando de uma brincadeira antiga entre crianças, o famoso telefone sem fio: a ideia é que no início a criança tenha uma frase secreta e precisa passar essa frase para uma outra criança sem repetir as palavras.

[00:53] E a moral da história é que a frase muda. Cada criança escuta uma frase um pouco diferente, e no final o que era “xyz” se tornou outra coisa, uma frase muitas vezes sem sentido ou com um sentido totalmente diferente. É uma brincadeira legal.

[01:13] O problema é que nós também brincamos de telefone sem fio no desenvolvimento. Não é exclusividade do desenvolvimento, é algo do humano, que é a comunicação falha. Na hora de colocar essas ideias no papel ou comunicar verbalmente acontecem falhas. Isso é coisa do humano.

[01:38] Ou seja, na equipe de desenvolvimento também há essas comunicações, ao repassar os requisitos, e acontecem falhas.

[01:55] Só para ilustrar isso num desenvolvimento clássico, no início temos aquela pessoa que sabe qual feature, qual funcionalidade nós deveríamos implementar. É o cliente, idealmente. Mas se não existe o cliente perto, é o PO (Product Owner), pensando no desenvolvimento ágil, no desenvolvimento SCRUM.

[02:15] Ou seja, na verdade bem no início, já temos talvez uma comunicação, porque o cliente precisa passar o conhecimento para o PO. Esse PO, essa pessoa que domina o negócio, sabe qual funcionalidade, qual novidade, qual ideia deveríamos implementar e precisa passar isso para o analista de negócio, aquele que está na equipe e refina os features, as funcionalidades, e divide em stories.

[02:45] Eu estou seguindo a nomenclatura mais ágil, esses casos de usos, talvez; criar um diagrama de caso de uso etc., como se fosse algo mais formal. Mas o analista de sistema tenta refinar essa funcionalidade, esse é o trabalho dele, para os desenvolvedores depois poderem implementar.

[03:05] Então, nos stories temos comunicação verbal, comunicação escrita, ferramentas envolvidas, e isso tudo pode gerar um conflito.

[03:17] Então o desenvolvedor lê os stories e tenta dividir isso em mais tarefas, pequenos tasks para colocar isso no Sprint, desenvolver aquela história e transformar aquilo em código.

[03:36] E paralelamente, não precisa ser um depois do outro, os testadores, o QA (Quality Assurance) cria os critérios de aceitação e executa os testes para validar se aquela ideia no início realmente foi implementada como foi pensada.

[03:56] Então reparem que tem vários pontos de atenção, que podem dar errado. Aquele resultado no final, a aplicação, nem sempre é o que o cliente queria ou pensou que deveria ser.

[04:13] E o BDD tenta resolver isso, tenta dar uma solução, um processo para melhorar isso. Então o BDD, na essência, é sobre colaboração, sobre melhorar a comunicação. E menos sobre Cucumber, JBehave, ou outras ferramentas famosas.

[04:32] Essas ferramentas fazem parte. Mas a essência é juntar a galera, principalmente no início, criar esse conhecimento comum, fazer todos os envolvidos, os testadores, os desenvolvedores, analistas, o cliente, entenderem e esclarecerem as dúvidas que existem relacionadas com aquele feature, aquela funcionalidade, para realmente entenderem o que a aplicação deveria fazer.

[05:03] O resultado dessa reunião, desse conhecimento compartilhado sobre a aplicação é a segunda fase desse processo, chamada formalização. São documentos que descrevem realmente os critérios de aceitação. Então temos uma funcionalidade, e quais são os critérios de aceitação? Como a aplicação no final poderia ser testada?

[05:31] Mas nessa etapa não tem nada de código ainda, é escrita numa linguagem entendível por todos, uma linguagem de negócio.

[05:43] Então agora temos um conhecimento comum e todos sabem como validar isso de maneira semelhante. Aqui entram esses famosos Given-When-Then, que todo mundo já ouviu falar.

[05:59] Então eu tenho agora esse conhecimento comum, eu tenho essa formalização, esses critérios de aceitação. E agora é hora de realmente transformar isso em código, automatizar. E aí sim entra o Cucumber. Entra agora o desenvolvedor usando o TDD (Test-driven development) para transformar isso num design guiado pelos testes.

[06:27] E entra o Gherkin, que sabe interpretar essa linguagem natural. Ou seja, essa é a fase de realmente implementar as coisas e fazer funcionar baseado naqueles critérios de aceitação.

[06:44] Então sabemos quais são as funcionalidades, temos a ideia das histórias, criamos os critérios de aceitação, e agora sim vamos fazer aqueles critérios funcionarem, para realmente fazer também o que foi pedido, e nada além.

[07:00] E depois, validar através do PO, através do analista de negócio e de novo voltar à fase inicial. É um ciclo para descobrir novas coisas, ajustar o que precisa ser ajustado.

[07:18] Então a essência é a colaboração. Fazer o negócio ser entendido por todos, e definir os critérios de aceitação já no início do processo. No início do Sprint todos os envolvidos sabem o que tem que ser feito e têm os critérios de aceitação já definidos.

[07:44] E o resto é consequência, são ferramentas como o Cucumber, que te dão a estrutura, facilitam a implementação desse processo.

[08:00] Uma vez entendido isso, então vamos olhar um pouco na aplicação que vamos utilizar para realmente começar a definir as nossas features, e definir esses critérios de aceitação.

[08:14] Te vejo no próximo vídeo.

[00:00] Olá, boas-vindas de volta. Você já tem agora uma noção do que é BDD, onde ele se encaixa no mundo ágil e no desenvolvimento. Agora o que queremos é fazer as coisas na prática. Ou seja, aprender o BDD realmente diante de um projeto mais real possível, isso com a plataforma Java e as ferramentas ao redor.

[00:24] Nesse vídeo eu vou gastar um pouco de tempo para importar e fazer toda essa preparação do ambiente. Para quem já é um desenvolvedor experiente, acho que pode acelerar esse vídeo bastante. Para quem está engatinhando com Java e tem mais um perfil de QA, vai com calma e assista a esses próximos dois vídeos comigo.

[00:53] O que vocês vão precisar na máquina para esse projeto funcionar? Primeira coisa, vocês precisam ter o Java instalado, é claro. Preferencialmente o JDK. Na verdade, para rodar o Eclipse basta o JRE. Mas se vocês quiserem fazer algo na linha de comando, por exemplo, com o Maven, seria útil instalar o JDK.

[01:23] Abrindo um prompt, a famosa linha de comando, o comando Java deveria funcionar, java -version. E também o comando javac -version. E isso normalmente no Windows não funciona por padrão, mesmo instalando o JDK.

[01:53] Então você precisa ir nas propriedades do seu computador, e entrar nas configurações do sistema para as variáveis de ambiente. Para o javac funcionar vocês precisam adicionar a pasta do javac no Path.

[02:22] No meu caso, o Java foi instalado em “Program Files\Java\jdk1.8.0_261\bin”. Adicionando isso vai funcionar. Já aproveitando, repara que eu também adicionei a pasta do Maven. O Maven é o gerenciador de dependências do Java que baixa as bibliotecas e executa e consegue compilar todo o ciclo de vida. Eu também já adicionei.

[02:46] Então quando eu te falo sobre o Maven vocês também sabem que para funcionar na linha de comando também precisamos adicioná-lo na pasta “\bin”, porque é onde tem os binários.

[02:56] Eu já tinha feito isso, vou fechar todas essas janelas. Então o javac funciona e o Java funciona.

[03:09] Além do Java, eu vou precisar no mínimo do Eclipse, aquele Eclipse Java Web. Como eu estou usando um projeto baseado em Spring, eu baixei o Spring Tool Suite.

[03:31] Vou pesquisar por “spring tool suite” no navegador e clicar no primeiro link. É um Eclipse com um monte de plugins para facilitar o desenvolvimento com Spring. Pode reparar que é o mesmo ambiente de Eclipse.

[03:48] E faz sentido usar, porque tem algumas facilidades. Mas a princípio bastaria um Eclipse Web ou um Eclipse Java padrão.

[04:00] Então baixei o Java, instalei e configurei na linha de comando. Baixei o Eclipse do Spring, o Spring Tool Suite e instalei. É só dar dois cliques que o arquivo Java vai instalar.

[04:17] Eu tenho também a pasta extraída do Eclipse. Vou inicializar o Spring Tool Suite, que na verdade é o Eclipse do Spring.

[04:29] Além disso eu também já criei uma pasta chamada “workspace”. Porque o Eclipse vai me perguntar onde eu quero que meus arquivos fiquem. Vai ser nessa pasta, que inclusive já abriu.

[04:45] E eu também já baixei e extraí o projeto da atividade anterior a esse vídeo. Aqui está aquele leilão que vocês já baixaram. Quem não fez, faz isso agora.

[04:59] Então temos o workspace, meu Spring Tool Suite já está apontando. E agora eu vou importar o projeto, clicando no canto superior esquerdo da tela em “File > Import”. Eu vou procurar pelo Maven, que é meu gerenciador de dependências por baixo dos panos. Seleciono “Existing Maven Project” e clico em “Next”.

[05:28] Depois clico em “Browse”, ele abre a minha pasta “workspace”, que eu já tinha apontado ao Eclipse, e vou selecionar a pasta “leilao”, que eu já tinha extraído. Repare que ele já reconhece o arquivo de configuração Maven, o famoso “pom.xml” e clico em “Finish”.

[05:48] Eu estou dando realmente passo a passo para quem não está tão acostumado com esse ambiente. E agora vai demorar um pouco. Eu já fiz isso antes, então passa muito mais rápido, ele já está acabando.

[06:02] Mas quando vocês fazem isso pela primeira vez, vai demorar. Se prepara porque se vocês fazem isso usando o Maven pela primeira vez, vai demorar bastante. Ele fica rodando e realmente demora até o projeto inicializar corretamente, porque o Maven, por baixo dos panos fica baixando todas essas bibliotecas. Isso tudo já tinha na minha máquina local. Quem não fez isso antes, vai demorar, tem que ter um pouco de paciência.

[06:37] Então temos agora um clássico projeto Maven, com o “src/main/java”, os recursos da aplicação, os arquivos de fonte dos testes e os recursos dos testes, além de alguns outros arquivos.

[06:51] O que eu queria fazer agora com vocês para pelo menos terminar essa aula é rodar o projeto, para no próximo vídeo eu entrar em alguns detalhes a mais.

[07:01] Esse projeto é baseado no Spring Boot. Então temos uma classe com um Main que inicializa. Não precisa de servidor extra, Tomcat, nada disso, porque o Spring já tem isso embutido.

[07:19] Então na teoria basta rodar isso como aplicação Java, e até vai funcionar parcialmente. Parcialmente, porque essa aplicação foi configurada em perfis que rodam em ambientes para representar ambientes no desenvolvimento. Como eu falei, eu queria chegar com essa aplicação o mais perto de um projeto real.

[07:41] Então vocês vão ver que, por exemplo, no arquivo dos recursos existem propriedades para ambiente de teste e para ambiente de produção. A diferença é basicamente que o ambiente de teste tem um banco de dados configurado que roda em memória, o famoso H2. O ambiente de produção usa o MariaDB, do MySQL.

[08:08] Ou seja, na hora de rodar eu preciso definir que eu quero executar agora um ambiente de teste. E também já deixei uma dica: basta adicionar o parâmetro -Dspring.profiles.active=test na hora de rodar essa classe main.

[08:25] Quem usa o Spring Tool tem uma facilidade. Eu vou clicar com o botão direito e escolher “Run As > Spring Boot App”, mas poderia ser “Java Application” também.

[08:38] Ele vai rodar, mas ele não está configurado ainda para rodar no ambiente de teste. E já está subindo, funcionou. Mas acessando agora não vai mostrar dados, nada de padrão, porque ele não achou as nossas configurações do banco de dados.

[08:55] Então vou parar e vou agora entrar nas configurações, em “Run Configurations”. E podemos adicionar o profile. Esse diálogo só existe para quem tem o Spring Tool Suite instalado. Para quem não tem o Eclipse específico do Spring precisa fazer algo a mais.

[09:28] Para quem não tem precisa adicionar o parâmetro -Dspring.profile.active=test na aba “Arguments”, no campo “VM Arguments”. Com isso o Spring sabe que precisa ativar o ambiente de teste.

[09:37] Como eu tenho o Spring Tool Suite, eu consigo selecionar confortavelmente o profile de teste na aba “Spring Boot”. É uma pequena ajuda. Em seguida clico em “Run”. Vai subir a aplicação. E já foi, realmente carregou.

[10:09] E reparem que eu configurei o log apenas para warning, logging.level.root=WARN então ele mostrou muito menos mensagens para que caibam as configurações certas.

[10:19] Acessando agora no navegador “localhost:8080”, já mostra a página do padrão. Eu já tenho um usuário, mas quando eu clico em “Login” não vai funcionar, porque ele ainda não tem dados.

[10:36] Mas isso vou te mostrar no próximo vídeo, como nós realmente populamos as coisas e trabalhamos com os testes. E também vou mostrar algumas configurações a mais. Então ainda estamos nessa fase de ambientalização, se é que existe essa palavra, começando com o projeto. Te vejo no próximo vídeo. Até lá.