Escrevendo seu primeiro cenário Cucumber

Previamente postei neste blog alguns artigos a respeito do que é BDD, para que serve e como aplicá-lo. Veja exemplos aqui: artigos-bdd-ciclosw

Hoje vamos dar continuidade aos estudos sobre implementação do BDD como método de ATDD, ou seja, a utilização dele para o processo de escrita de cenários de aceite. O foco aqui estará para os testes automatizados implementados pela figura do QA em um contexto de entrega incremental, onde as funcionalidades de um sistema de UI é separado por casos de uso.

Eu também descrevi aqui como implementar seu primeiro cenário de teste automatizado  com BDD utilizando a ferramenta SpecFlow e código C#. Mas hoje quero dar ênfase à escrita de uma feature, que vem a ser a parte de negócio da implementação BDD através do Cucumber, com base na sintaxe Gherkin.

 

Origem do Cucumber

Segundo a documentação do cucumber.io: “Cucumber é uma ferramenta que suporta Desenvolvimento guiado a comportamento (BDD, na tradução livre) – um processo de desenvolvimento de software que visa melhorar a qualidade do software e reduzir custos de manutenção.”.

Essa ferramenta foi criada em 2008, por Aslak Hellesøy, que foi desenvolvedor na ThoughtWorks e em 2014 fundou a empresa Cucumber Ltd. De acordo com suas palavras à uma entrevista da InfoQ: “Eu fui consultor por 10 anos antes de criar a ferramenta Cucumber. Nos primeiros 5 anos de minha carreira, todos os projetos nos quais trabalhei tinham os mesmos problemas:

  • Eu muitas vezes não sabia se tinha entendido todos os requisitos;
  • Eu achei difícil confiar no resultado daquilo que estávamos construindo
  • Eu tinha medo de mudar código pré-existente, sem saber o que poderia quebrar com as mudanças
  • Nós estávamos constantemente atrasados com as entregas

E continua: “Com o BDD, * todos * os testes são testes de aceitação do cliente, escritos em linguagem simples (humana) para que os interessados ​​não técnicos possam compreendê-los. Então, o Cucumber combina especificações de requisitos, testes automatizados e documentação viva em um único formato chamado Gherkin, que é simplesmente inglês com um pouco mais de estrutura.”.

 

Como escrever sua primeira feature

É importante salientar que, tecnicamente, existem diversas ferramentas que podem ser utilizadas para implementar BDD: Cucumber, SpecFlow, JBehave, RSpec, Jasmine, Cucumber-js, Lettuce, Lettuce, etc. E que BDD é um processo maior que a automação de testes!!!

Mas, considerando o cenário que utiliza automação de testes, como citado acima, o fluxo de desenvolvimento BDD pode ser ordenado da seguinte forma:

1. Descrever funcionalidades      2. Implementar cenários   3. Executar cenários

Na etapa Descrever Funcionalidades é a qual: entendemos requisitos e prioridades; listamos cenários de uso, seus fluxos e resultados esperados.

Na etapa Implementar Cenários é a qual: escrevemos os cenários de ATDD com gherkin; implementamos seus steps e page-objects; gravamos os cenários em uma ferramenta de controle de versão.

Na etapa Executar Cenários é a qual: organizamos os cenários em suítes de testes; configuramos variáveis de ambiente, drivers e runners dos testes para a execução dos cenários; integramos os cenários a uma  ferramenta de  integração contínua, caso necessário.

 

 

Agora vamos para a parte prática!

Continuar lendo

Por quê aplicar BDD?

Behavior Driven Development, ou simplesmente BDD, é uma metodologia para desenvolvimento de produtos que foi criada como técnica para atender às demandas que o TDD não conseguiu suprir. Ela surgiu como proposta ao contexto da codificação de software. A diferença entre as duas técnicas, TDD e BDD, foi explicada aqui: diferenca-entre-tdd-e-bdd/

Hoje, enxergo o BDD como prática colaborativa, porque sua aplicação efetiva é proveniente da interação entre pessoas, com propósito na melhoria da comunicação entre elas. Ou seja, esta é uma ferramenta que não está mais restrita ao âmbito técnico da construção do produto, porque passa por diversas camadas anteriores ao seu desenvolvimento: entendimento das necessidades do cliente e domínio de negócio por toda a equipe desenvolvedora do produto.

Benefícios

O BDD é uma ferramenta que detalha a camada do negócio e chega à área técnica para a correta implementação de comportamentos do produto. Isso porque ela:

  • Facilita o entendimento do negócio;
  • Descreve o resultado esperado pelo cliente;
  • Promove a discussão do negócio;
  • Delimita escopo do produto;
  • Previne a ocorrência de falhas no produto.

Todos os benefícios listados acima contam com esta origem: especificação por exemplos, ferramenta que deve participar nas conversas com o cliente. Assim, quando em sua aplicação, o negócio passa a ser especificado em formato de pequenos exemplos de uso: cenários, contando com critérios de aceite bem definidos: comportamento do produto, o cliente tem sua visão entendida e detalhada para a equipe técnica que irá construir seu produto. E isso resulta em qualidade na entrega do produto, já que ele contará com as funcionalidades desejadas por quem o solicitou.

Como aplicar?

Continuar lendo

Portifólio de Cursos

Oi pessoal,

Se você tem interesse em realizar aulas particulares nos seguintes temas, por favor, me procure no e-mail ciclosw@gmail.com

Garanto que tenho um material bem especial para vocês. 🙂

 

>> Curso Prático de Selenium WebDriver com Java e TestNG

>> Curso Prático de Selenium WebDriver com C# e SpecFlow

>> Curso Prático de Selenium WebDriver com Ruby, Capybara e Cucumber

>> Curso Prático de Testes de API com Ruby, HTTParty e Cucumber

Continuar lendo

Algumas aplicações para a ferramenta Selenium IDE

big-logoA ferramenta Selenium IDE é um plugin desenvolvido para o navegador Firefox. Sua principal função é gravar e executar scripts automatizados de testes funcionais. Ela atualmente apresenta também a possibilidade de edição destes scripts em linguagens de programação como: Java, Ruby, C#, Python e JavaScript.

Em um passado recente, período entre 2007 e 2012, seu uso foi difundido nas empresas que produzem software do Brasil. Isso impulsionou uso de automatização dos testes como meio de promover e facilitar a regressão na manutenção dos sistemas-produto e inclusive motivou estudos a respeito das atividades do testador, neste contexto.

Recentemente, diversas fontes têm apontado a ferramenta Selenium IDE de uso não recomendado, apesar de sua evolução. O discurso comum é de que ela enrijece a automação e por isso provoca a constante necessidade de revisão dos scripts gerados. Ela também apresenta limitações quanto ao: compatibilidade (gravação restrita ao Firefox, incompatível com algumas versões), integração aos scripts automáticos de páginas web (ex.: AJAX, JavaScript) e interação com as janelas do sistema operacional (não oferece suporte).

Continuar lendo

1º Encontro de Testers de Salvador

O Grupo Teste de Software Salvador está promovendo o 1º Encontro de Testers de Salvador. Integrantes do grupo responderam a um questionário para promover o 1º Encontro de Testers de Salvador/BA.

Eles decidiram que:
  • O espaço deve ser virtual – Hangout, Skype, etc.
  • O formato deve ser discursivo, onde todos os participantes devem interagir para expor assuntos e ideias;
  • O evento deve estar aberto a todos os profissionais de TI, interessados pelo tema de testes de software;
  • A duração deve ser aberta, com o mínimo de 30 minutos;
  •  Nossos encontros devem ser bimestrais.
Dito tudo isso, reserve tempo na agenda para nosso primeiro encontro. Ele acontecerá daqui 1 semaninha, dia 20/07, à partir das 19:30, via Skype.
A pauta também foi elaborada por eles. Os temas citados foram:
  • Mercado de testes em Salvador/Bahia, principais empresas, tendências em certificações, perspectivas da área;
  • Perfil e atividades do testador;
  • Automação de testes;
  • Movimento Ágil – teste ágil;
Não deixe de participar e enviar sugestões para o evento!
logo

Introdução ao Teste de Software

Você estudante de TI, quer iniciar a carreira em testes e não sabe por onde começar? Você desenvolvedor já atuante na área deseja estar preparado para o mercado e potencializar sua atuação?

Estão abertas as inscrições para o curso EAD de Formação em testes de Software – Introdução ao Teste de Software.

Data: 29 e 30 de junho
Investimento = R$120,00 (valor promocional até dia 22/06)
Carga horária: 4 horas
* Acompanha emissão de certificado

Para mais detalhes, confira os dados abaixo ou clique no link:

Abrangência dos Testes Unitários

Os testes unitários são costumeiramente escritos pelos programadores dos módulos de um sistema. Ferramentas como JUnit e NUnit auxiliam na automação desta tarefa porque fornecem métodos próprios ao desenvolvimento e execução dos testes.

Os métodos dos testes unitários devem estar implementados em uma classe à parte que acompanhe as funcionalidades programadas para aquele módulo em questão. Um exemplo seria: na arquitetura de sistemas MVC (Model-View-Controller), de model Usuario, controller UsuarioController e view cadastrarUsuario.xhtml, o módulo de cadastro de usuário conteria a classe UsuarioTest. Esta classe deve conter basicamente a validação da função principal do módulo: cadastrar a entidade usuário. Mas, para que o teste cumpra o objetivo de detectar falhas no módulo, é adequado que se valide também os caminhos alternativos à ação cadastrar usuário. Exemplos são: testar nulidade de dados obrigatórios para a entidade, duplicar cadastro de usuário, entre outros.

Por permissão da arquitetura projetada ou por opção do programador, é possível que se realize teste unitário para todas as camadas de uma arquitetura: camada de banco de dados, de modelagem, de controle, de manipulação da apresentação, de apresentação, de integração, etc. No entanto, por conta do próprio conceito de unicidade, é adequado que se analise apenas um escopo de código-fonte por vez. Esse escopo pode corresponder a um método específico ou a um pequeno conjunto deles que levem ao caminho de cadastro com sucesso ou sem sucesso. Um exemplo da primeira situação seria o método testarCadastroUsuario(), relacionado com o método de cadastro com sucesso do UsuarioController, inserirUsuario(). Um exemplo do segundo seria testarUnicidadeUsuario(), relacionado aos métodos inserirUsuario() e validarUnicidade() do UsuarioController.

O ideal é que se reserve os testes unitários para as camadas de banco de dados e controle/serviço. Isso porque este é o espaço da arquitetura que geralmente abriga a maior parte da implementação das regras de negócio, à nível de código-fonte. Evidente que, caso haja mais camadas de persistência de funções/transações e validação dos dados da entidade, elas devem participar deste conjunto.

A camada de apresentação também pode ser validada com o auxílio das ferramentas de testes unitários, a exemplo do Selenium WebDriver que se relaciona com o JUnit, NUnit entre outras. Mas é importante que se observe o objetivo do teste deixará de ser “avaliar uma função unitária” (teste unitário) para “avaliar um fluxo de atividade sobre o sistema” (teste de sistema).

O teste unitário avalia unidades de código-fonte, ele é intrinsecamente, um teste de caixa branca voltado para a análise de uma função específica do sistema. Ele se relaciona com cada método codificado para a persistência ou validação de regra de negócio. Já o teste de sistema tem foco na execução de um fluxo de sistema que conclua uma atividade. Ele pode até ser à nível de código-fonte, mas seu resultado só pode ser observado à nível usual. Ele se relaciona a uma ação sobre o sistema: clique do botão inserir, na tela do sistema; disparo da trigger de atualização da lista de usuários, no banco de dados, etc.

No final das contas, além do conceito de testes unitários os seguintes fatores irão influenciar na abrangência de aplicação deles: o nível de flexibilidade da arquitetura do software, se o projeto permite que se crie classes integradas à todas as camadas do projeto; o ritmo do projeto: qual a frequência de entrega das atividades -final do dia, semana, mês; tamanho e objetivo do projeto: o custo X benefício deve ser avaliado; entre outros.

Curso de Selenium WebDriver – Aula 5 – WebDriver além do Firefox

O navegador Firefox é o browser oficial do Selenium. Isso porque o Selenium IDE foi criado inicialmente para ser um plugin deste navegador. Antes da criação do Selenium WebDriver, ou Selenium 2, era necessário utilizar o Selenium RC para rodar os testes criados no Selenium IDE remotamente ou em outros navegadores.

Ao informar o seguinte trecho de código-fonte na classe de testes suportada pelo Selenium WebDriver, o teste roda sem problemas no navegador Firefox (para ver as configurações gerais do projeto acesse a aula 1 do curso neste blog):

  • WebDriver driver = new FirefoxDriver();

Seria bastante óbvio e cômodo apenas substituir a classe FirefoxDriver pelos demais navegadores a que o Selenium oferece suporte – Chrome, Internet Explorer, Safari, entre outros. No entanto, não é bem assim. Antes, é necessário configurar o arquivo Pom.xml do projeto, informando novas referências ao browser em questão e informar no código do teste o caminho que o executável dele está disponível.

Vejamos o exemplo do navegador Chrome, em ambiente Linux, IDE Eclipse, plataforma Java  e projeto integrado com o plugin Maven:

  1. Abrir o arquivo Pom.xml do projeto e informar a dependência para o chromedriver.
    1. <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-chrome-driver</artifactId>
      <version>2.43.1</version>
      </dependency>

    chrome-driver

    chrome-driver

  2. Realizar o download do “executável” do chromedriver no link < lembrar de baixar o executável compatível com a versão do seu sistema operacional – 32 ou 64 bits – no meu caso é a versão 64bits >;
  3. Descompactar o pacote do executável do chromedriver em uma pasta do sistema operacional;
  4. Passar o caminho da pasta do executável do chromedriver no código-fonte do teste
    1. System.setProperty(“webdriver.chrome.driver”, “/home/lorena/workspace/chrome64/chromedriver”);
  5. Escrever um método de teste:

    Método de testes básico para execução sobre o Google Chrome

    Método de testes básico para execução sobre o Google Chrome

  6. Executar o teste [utilizei o JUnit 4 para rodar o teste]:
    Teste em execução no Google Chrome

    Teste em execução no Google Chrome

    Resultado do teste no JUnit

    Resultado do teste no JUnit

Link para o download da classe ChromeTest.

Link para o download do projeto.

Referências:

https://sites.google.com/a/chromium.org/chromedriver/home

http://docs.seleniumhq.org/docs/03_webdriver.jsp#chrome-driver

http://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/chrome/ChromeDriver.html