Curso de Selenium WebDriver – Aula 6 – Exportando classes do IDE e Importando no WebDriver

Olá gente,

Primeiro venho me desculpar pela demora em postar a aula final do curso de Selenium WebDriver. Eu bem sei que quem quer faz, que desculpas não servem muito. Mas é que passei por momentos turbulentos nesse último semestre. Enfim recuperada e tendo devidamente superado todos os obstáculos da vida, volto a humildemente escrever-vos.

A ferramenta Selenium é muito poderosa! Ela te permite gravar e reproduzir ações, diretamente na interface de um sistema, através da sua versão IDE. Ela te permite também criar esses mesmos passos via código-fonte, com o uso da sua versão WebDriver. Mas… e se eu precisar utilizar as duas coisas?

O Selenium IDE sempre disponibilizou a opção de criar um script de teste “codificado”. Lembro que ao utilizá-lo, anos atrás, já era possível exportar os casos de testes gravados nele para classes dos tipos C#, PHP, Java, Phyton, até mesmo Ruby. Sei que hoje existem muito mais tipos que estes citados.

Dito isto, tendo voltado o curso para a plataforma Java, você irá precisar das seguintes ferramentas para executar a exportação do IDE e importação no WebDriver:

  • Browser Firefox e plugin Selenium IDE – versão mais nova e compatível entre os dois
  • IDE para programação Java, equipado com o Maven (vide aula 1) e bibliotecas do WebDriver – recomendo o Eclipse IDE
  • JUnit – versão mínima 4
  • OBS.: Lembrando que utilizo o sistema operacional Ubuntu

Partindo da instalação do Selenium IDE, vamos seguir esses passos:

  1. Acessar o link de download da ferramenta pelo browser Firefox (estou utilizando a versão 34, a mais recente no momento);
  2. Clicar no link de download mais recente (2.7.0 atualmente). No popup que irá abrir, permitir a instalação.
  3. Permitir a instalação dos complementos associados (incluir o Java Formatters para este exemplo);
  4. Reiniciar o Firefox.
Confirmando a instalação do Selenium IDE

Confirmando a instalação do Selenium IDE

Gravando um caso de teste no Selenium IDE e o exportando

  1. No browser Firefox, escolher o menu Ferramentas > Selenium IDE;
  2. Clicar na ação Gravar, realizar uma ação no navegador e “pausar” a gravação;
  3. Exportar o teste no Selenium IDE, acessando o menu Arquivo > Exportar Teste Como > Java / JUnit 4/ WebDriver para uma pasta no sistema operacional. É importante manter a extensão .java do arquivo.
Concluindo a gravação de um teste com o Selenium IDE

Concluindo a gravação de um teste com o Selenium IDE

Importando o caso de teste gravado no IDE para o projeto Java

  1. Abrir a IDE de programação (estou utilizando o Eclipse JavaEE for Web Developers);
  2. Criar um projeto Java contendo o integrador Maven associado (Ver primeira Aula para saber como configurar);
  3. Configurar a dependência do JUnit na IDE [Ver este vídeo para saber como]. Sua versão deve ser compatível com o resultado oferecido pelo Selenium IDE (estou utilizando a versão 4.11);
  4. Copiar a suíte de testes exportada do IDE para dentro do projeto Java. O arquivo .java deve ser inserido na pasta scr/test/java;
  5. Resolver os conflitos de projeto que ocorrem com a inserção da nova classe, ex.: importação da classe, nome da classe, chamada aos métodos, anotações. Lembrar de realizar “extends” para a classe TestCase e a importar.
    OBS.: Eu adicionei um construtor à classe passando o nome do caso de testes public PesquisaGoogle(String nomeTeste){super(nomeTeste)}, além do método public void testApp(){assertTrue(true);}
Importando uma suíte de testes do Selenium IDE como uma classe de testes JUnit no Eclipse

Importando uma suíte de testes do Selenium IDE como uma classe de testes JUnit no Eclipse

Executando o teste:

  1. Abrir a classe de testes importada no projeto (no projeto em questão é a classe PesquisaGoogle.java inserida na pasta scr/test/java).
  2. Verificar o resultado da execução na barra de execuções do JUnit na IDE.
Resultado de execução do teste

Resultado de execução do teste

Link para download do projeto

Enfim, nosso querido curso de Selenium WebDriver chega ao seu fim. Querendo Deus, este será o primeiro de muitos. Fica então o espaço de Comentários aberto para receber dúvidas, críticas, sugestões, melhorias/alternativas de conteúdo a estes posts.

Estou muito grata pelo retorno de vocês! Feliz 2015 a todos! =]

Padrão para Testes ISO/IEC/IEEE 29119

A instituição ISO está lançando o padrão internacional ISO/IEC/IEEE 29119 como um conjunto de práticas que devem ser seguidas por “qualquer organização, contendo qualquer ciclo de vida de desenvolvimento de software”. Ele deverá ser constituído por 5 parte, das quais 4 já foram divulgadas entre os anos de 2013 e 2014 [partes 1 a 4] e 1 está prevista para 2015 [parte 5]:

  1. Conceitos e Definições
  2. Processos de Teste
  3. Documentação de Teste
  4. Técnicas de Teste
  5. Testes baseados em Keyword

Esse padrão emprega as especificações de outros: IEEE 829 e 1008 e BS 7925-1 e 2. Por isso sua função será também substituí-los. Ele começou a ser escrito no ano de 2007 e desde de então vem sendo formulado por um comitê, a equipe WG26.

Apesar das críticas e movimentos contrários à sua formação, o padrão IEEE 29119 parece estar atendendo a pedidos do mercado, pois inúmeros gestores têm cobrado a normatização do processo de testes com vistas ao estabelecimento e garantia de melhor funcionamento deste setor e entrega de resultados por suas empresas. Ainda que isso não possa ser inferido pela prática de adoção de um padrão, seja este ou não, a simples tentativa em fazê-lo tem ganho entusiasmo no meio executivo de TI.

A principal preocupação da comunidade de testes em relação a esse padrão tem sido: 1- falta de consenso entre o comitê e a comunidade de testes; 2 – necessidade de documentação extensa e de difícil implementação prevista no padrão; 3 – engessamento ou retrocesso do processo de testes pela adoção do padrão; 4 – impacto em outras áreas do ciclo que não sejam teste.

Com isso, só nos resta ponderar as questões referentes à adoção do padrão e os impactos que isso poderá causar à TI. Os pontos citados foram considerados por representar maior criticidade à essa adoção.

Pontos à favor do padrão:

  • Empresas e Governo = As empresas e o governo enxergam uma certificação como referencial de correto funcionamento e garantia de qualidade do processo;
  • Opções de Certificação = O padrão passará a ser mais uma opção de certificação para as empresas;
  • Documentação = Tanto a equipe de testes como as demais, que constituam o ciclo de desenvolvimento de software, precisarão escrever mais a respeito de seus processos, técnicas e produtos de trabalho;
  • Discussão = A possibilidade de adoção do padrão fomentará conversas a respeito do processo de testes da empresa.

Pontos contra o padrão:

  • Comunidade de Testes = Uma das principais abordagens de testes utilizadas pelos testadores/empresas está sendo suprimida no padrão, conforme discussão da comunidade de testes: Context-Driven Testing;
  • Testers = Os profissionais de testes precisarão adequar suas atividades às diretrizes do padrão e o setor como um todo estará submisso, no que tange à produção de artefatos, ao que for produzido previamente como documentação de projeto;
  • Empresas e Governo = O setor responsável pela adoção dos padrões geralmente não tem visão geral do processo de desenvolvimento do software. Isso porque ele não é constituído por técnicos de TI ou os profissionais que efetivamente projetam/programam/testam o software;
  • Influência = O peso de uma certificação ISO conta pontos ao favor da empresa que a adotar. O risco é influenciá-la o mercado ao ponto de o cliente passar a exigi-la como pretexto para o fechamento de negócios.

Na minha visão, qualquer outra inferência a respeito da adoção ou não do padrão ISO 29119 pelas empresas que desenvolvem software seria prematura. Portanto, só nos resta aguardar a completa publicação do padrão e novos capítulos da discussão comitê WG26 x comunidade de testes para opinar a respeito.

Uma visão geral do padrão pode ser encontrada no link: http://www.bcs.org/upload/pdf/sreid-120913.pdf

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.

Mudanças previstas para TI a partir de 2015

Vai chegando o final de ano e é comum que aconteçam algumas previsões para o ano que está por chegar. Basta observar os sites e outras mídias que direcionam notícias para a vida das celebridades: “Em 2015 haverá X casamentos e Y separações”. Mas… por que não trazer isto para o domínio profissional? Por que não elevar este tema a um assunto que tange essa importante parte das nossas vidas?  Pensando nisto O CEO Cezar Taurion, escreveu este artigo intrigante e nem um pouco superficial ou de teor sobrenatural, que nos impele a refletir justamente sobre a questão dos avanços da TI a partir do próximo ano. Vale à pena despender alguns minutos para ler e pensar sobre o conteúdo do artigo! Leitura: artigo: TI está despreparada para quatro tsunamis que se aproximam Questão Principal: Os rumos da TI Reflexões: Existem padrões na TI? Como “prever” as mudanças da TI?  Como estar preparados para enfrentar tais inovações? Texto complementar: 10 tendências de TI para 2015 Feliz 2015!  🙂 Referências: http://computerworld.com.br/tecnologia/2014/12/15/ti-esta-despreparada-para-quatro-tsunamis-que-se-aproximam/ http://computerworld.com.br/tecnologia/2014/12/09/idc-lista-10-tendencias-de-ti-para-2015/