Posts Tagged ‘Testes’

Você automatiza seus testes de aceitação?

Wednesday, September 26th, 2007

O Danilo Sato escreveu um post muito bom sobre automatização de testes de aceitação:

“Muitas equipes XP não automatizam seus testes de aceitação. Essa é uma afirmação dura, porém muito comum de acontecer. A equipe abraça TDD e testes de unidade automatizados, porém quando chega a hora dos testes de aceitação, a coisa complica. Por que isso acontece? Como melhorar essa situação?”

Testes de aceitação são essenciais e automatizá-los é extremamente desejável!

Quem acompanha meu blog já deve ter percebido que teste de software é um assunto que me interessa bastante. Ultimamente tenho trabalhado muito focado na qualidade dos softwares que entregamos na minha equipe e por isso estou constantemente explorando novas maneiras de testar ou procurando melhorar as maneiras antigas.

Nos últimos sprints temos feito da seguinte forma: o desenvolvedor que trabalhar no desenvolvimento de uma história não pode fazer testes de aceitação da mesma. Desta forma cada um sempre testa o que o outro fez (estamos usando Selenium para este tipo de teste).

Ao fim do 4o. sprint temos uma suite de testes expressiva que cobre praticamente 100% do que foi desenvolvido. Realmente percebemos que aqueles bugs extremamente simples que normalmente são encontrados em QA ou mesmo em produção foram encontrados em tempo de desenvolvimento e corrigidos com rapidez.

Rodando automaticamente estes testes são uma ferramenta poderosíssima para ajudar a garantir a qualidade da aplicação.

Recomendo fortemente a leitura do post do Danilo!

Mock Objects em excesso podem atrapalhar

Tuesday, August 28th, 2007

Acabo de ler na Artima um artigo sobre o uso excessivo de Mock Objects.

Fazer testes unitários pode não ser a tarefa mais fácil do mundo quando suas classes dependem de sistemas externos que você não controla como banco de dados, webservices e qualquer outra coisa que não faz parte do seu sistema. É aí que entram os Mock Objects, que são objetos que servem para “simular” as dependências das suas classes. Eles possuem comportamento controlado e fazem exatamente o que você definir, tornando os resultados das chamadas às dependências de um código totalmente previsíveis. Sabendo que todas as dependências estão funcionando corretamente, qualquer falha que aconteça nos testes está com certeza no local (método, classe, etc) testado.

O problema é quando decide-se simular todas as dependências. Isso é um pouco controverso porque na verdade quando você está fazendo testes unitários o certo mesmo é isolar o método e “mockar” todas as dependências. Porém em alguns casos isso acaba fazendo com que o teste fique muito complexo e difícil de ser entendido e mantido.

Além disso os testes com muitos Mocks podem acabar ocultando problemas na colaboração entre os objetos. Os objetos dependentes em uma determinada situação podem funcionar diferente de como foram “mockados” e pode ser interessante utilizar os objetos reais. Mas neste caso os seus testes seriam testes de integração e não testes unitários.

Ultimamente eu tenho optado por ir pelo caminho do meio e por isso concordo quase integralmente com a opinião do Alex Ruiz. Acredito que em boa parte das vezes você não precisa criar mocks de tudo que vê pela frente.

Um exemplo real é o sistema que estou trabalhando atualmente, onde estou desenvolvendo um cliente para um webservice REST. Este cliente é bem magro e basicamente ele pega XMLs de coisas que foram processadas no servidor (webservice) e transforma em objetos Java. Para isso o cliente acessa via HTTP um determinado endereço, obtém um XML que representa uma entidade do sistema, transforma em um objeto Java e retorna o resultado. Como este cliente é muito magro e praticamente não faz nenhum processamento, na maioria dos testes a única dependência que eu “mockei” foi o XML retornado, já que a única coisa não controlada pelo meu sistema é o canal HTTP e o servidor dos webservices que pode estar a qualquer momento offline e meu teste não pode falhar por causa disso. Para fazer isso eu injetei no repositório de objetos um HTTP Client mock que sempre retorna um XML válido. Com isso o meu teste verifica se o cliente retorna objetos Java corretos considerando que o webservice está funcionando. É claro que este não é o único tipo de teste que eu faço, tenho testes mais específicos para outras funcionalidades mais importantes, como a classe que transforma objetos em XML para Java e por aí vai.

Resumindo isso tudo, acho importante analisar cada caso e ver se há necessidade de criar testes canônicamente corretos ou se opções mais simples podem resolver o problema da mesma forma.

Testes com Selenium em vários browsers

Thursday, May 31st, 2007

Uma empresa chamada Reality QA criou um serviço interessante. Eles testam a sua aplicação web em vários browsers e sistemas operacionais diferentes utilizando como roteiro de teste um script Selenium. Os testes rodam automaticamente nas plataformas alvo e são gerados relatórios e screenshots dos testes na medida que eles vão acontecendo.

Para ver como funciona, veja o screencast produzido pela empresa.

Como essa ferramenta é beta eles ainda não cobram pelo serviço mas já tem um link de “Buy” preparado no site.

Hoje já é possível testar em vários browsers utilizando o Selenium Core só que você tem que fazer tudo manualmente (em cada browser que irá executar o teste você tem que abrir e executar o script na mão). Talvez eles tenham usado o Selenium Remote Control e criado proxies para várias plataformas diferentes.

Achei essa idéia interessante, vou estudar uma forma de fazer alguma coisa do tipo aqui para a empresa. Depois eu conto como foi.

Qual é o percentual ideal de cobertura de testes?

Wednesday, May 30th, 2007

Ontem estava tendo uma discussão com um amigo aqui do trabalho sobre cobertura de testes.

A nossa discussão começou quando eu fui mostrar para ele um teste de aceitação em Selenium que eu fiz para uma parte do sistema de gerenciamento de conteúdo da empresa.

Ele estava argumentando que acha que os testes de aceitação com Selenium não são tão interessantes porque eles são muito frágeis – alterações na interface podem quebrar os testes. Realmente isso pode acontecer. Mas se acontecer é só reescrever o teste, oras! Antes dele quebrar ele será executado várias vezes e só nisso várias horas preciosas podem ser economizadas.

Repare o seguinte: você efetivamente testará as telas do sistema navegando nele, incluindo, editando e removendo itens. Se este trabalho pode ser automatizado, porque não fazê-lo? Não é melhor gastar o seu tempo para elaborar novas táticas de testes e novos testes de outras partes do sistema ao invés de ficar navegando em todas as páginas “manualmente”?

Discussões deste tipo me fazem lembrar do manifesto Testivus, que dentre outras coisas prega que: “An imperfect test today is better than a perfect test someday” (Um teste imperfeito hoje é melhor do que um teste perfeito algum dia). Mesmo que os seus testes não sejam os melhores do mundo e que vez ou outra precisem ser corrigidos, é melhor tê-los do que não ter teste nenhum. Com o tempo a cultura de testes fica impregnada na equipe e os testes vão ficando cada vez melhores e mais numerosos.

É claro que eu não concordo que os testes possam ser um monte de lixo que não testam nada. Eu só acho que não se pode ter uma abordagem dogmática em relação aos testes. Se a sua aplicação tem 50% de cobertura de testes eu não acho isso ruim. Aliás, é BEM mais do que a maioria que existe por aí. Mesmo assim você pode (deve) testar bem mais.

Concluindo, eu particularmente gosto muito de utilizar a abordagem de desenvolvimento guiado por testes (TDD). Com TDD você tem uma cobertura de testes significativa já que os testes vão sendo escritos na medida que a aplicação é escrita. Porém se isso não puder ser feito por algum motivo, não acho correto estipular um percentual mínimo ideal de cobertura de testes. Só acho que deve-se testar muito e quanto mais, melhor.

Coincidentemente saiu ontem uma matéria no InfoQ sobre este mesmo assunto que vale apena a leitura.

Testes com JUnit + HSQLDB

Thursday, May 17th, 2007

Hoje fiz uma experiência legal no projeto em que estou trabalhando.

Estou há um tempinho bolando uma forma razoável para testar a aplicação de cabo a rabo. A única coisa que eu ainda não estava convencido totalmente sobre como fazer era testar as classes DAO ou fazer testes envolvendo elas.

Já lí em alguns lugares algumas pessoas falando que os testes não devem utilizar o banco de dados por uma série de motivos e que os DAOs sempre devem ser mocks. Até eu mesmo já cheguei a questionar se isso é realmente necessário. Depois de um tempinho com a idéia fermentando na cabeça eu penso o seguinte:

Primeiro: É interessante testar os DAOs porque você precisa garantir por exemplo que todos os campos estão sendo lidos corretamente para os objetos e que as queries funcionam. No caso de utilização de JPA/Hibernate ainda te ajuda a validar se o mapeamento objeto-relacional está correto.

Segundo: Existem alguns tipos de testes que podem ser feitos na sua aplicação. Se falarmos de teste unitário eu concordo que não deve haver utilização de banco de dados mas sim mocks para os DAOs e tudo mais que não for objeto do teste em questão. Porém para testes de integração ou aceitação é desejável que o banco de dados seja incluído no teste já que faz parte da aplicação.

Mas o problema de envolver o BD nos testes é que eles (os testes) ficam muito lentos e isso desfavorece o desenvolvimento guiado por testes, que eu não vivo sem. Se os testes demoram eles são executados menos vezes e isso não é bom. Sem contar que se os dados do banco forem modificados os testes quebram. Argh!

Eis que surge o HSQLDB. O HSQLDB é um banco de dados escrito em Java puro, tem driver JDBC que funciona direitinho e entende comandos SQL com JOINs, GROUP BYs e praticamente tudo mais que você utiliza numa aplicação que utiliza o banco de dados de forma NORMAL (normal = não utiliza aquelas tosqueiras proprietárias do BD que depois que se usa não dá mais para trocar nem a versão do bicho!).

O que eu fiz foi fazer com que os testes se conectassem num HSQLDB ao invés do banco de dados de desenvolvimento. Para melhorar, esse HSQLDB não está nem rodando em modo server em lugar nenhum. Ele é iniciando junto com os testes e roda em memória na mesma JVM que os testes rodam.

Quais foram os ganhos obtidos com este approach:

1) Minhas queries agora estão sendo testadas, assim como a criação dos meus objetos pelos DAOs.

2) Os testes estão muito rápidos, nem parece que usam banco de dados! Eu tinha criado duas suites de testes, uma que tinha testes com BD e outra sem BD. Isso nem será mais necessário agora.

3) Agora eu tenho a garantia de que os dados de teste não serão modificados e com isso os testes não quebrarão mais por este motivo. Sabendo que os dados não mudarão posso fazer testes mais completos e elaborados.

Porém também experimentei alguns pontos negativos:

1) Qualquer alteração de modelo tem que ser refletida no script de startup do HSQLDB. O script de startup é necessário para indicar quais tabelas com quais campos e dados ele criará em memória. São CREATE TABLEs com duas ou três coisinhas a mais, muda pouca coisa.

2) Em algumas aplicações que eu trabalho tem lógica da query no hint!!! Isso acontece porque lá na empresa tem um trilhão de aplicações rodando em produção no mesmo Oracle que eu rodo minha aplicação. Sendo assim se eu faço uma query ferrada eu derrubo o banco e junto com ele uma boa parte da empresa. Para evitar que isso aconteça os DBAs otimizam uma boa parte das queries que fazemos, só que as vezes a coisa fica tão dramática que os DBAs têm que fazer MAGIAS no hint para a query executar num tempo razoável. Aí eles mexem tanto no hint que no final a query depende do hint para funcionar, quando o hint deveria ser só para ela ficar mais rápida. Aí fica assim: com o hint a query retorna o resultado de um jeito e sem hint de outro! Como hint é coisa do Oracle e o HSQLDB entende como comentário, eventualmente não será possível testar uma ou outra query porque no HSQLDB o resultado será retornado sem executar a lógica contida no raio do hint!

Vou evoluir mais em cima desta idéia e na medida que as coisas forem acontecendo eu posto aqui mais comentários.

Test Driven Development in a nutshell

Wednesday, May 9th, 2007

Semana passada tivemos uma reunião na empresa em que trabalho sobre os procedimentos de controle de qualidade dos softwares que produzimos. Antes de fazer o release de um software é necessário que sejam tomadas algumas precauções básicas para garantir que ele funcione satisfatoriamente em produção e estávamos apresentando para os nossos gerentes e equipe de controle de qualidade da empresa as ferramentas e procedimentos adotados pela nossa equipe para isto.

Das várias medidas que estamos tomando, talvez a principal por ser a base para todas as outras direta ou indiretamente é o “desenvolvimento guiado pelos testes” ou “test driven development” (TDD para os mais íntimos).

No TDD você desenvolve os testes do software antes mesmo de desenvolver o software. A cada peça da aplicação que é construída uma série de testes são escritos ANTES do desenvolvimento para garantir que a aplicação funciona como deveria funcionar.

O conceito de TDD é bem simples de ser aplicado mas para quem não está acostumado com testes unitários e práticas de desenvolvimento ágil pode parecer meio estranho e ser um pouco mais difícil de entender.

Inspirado nesse cenário vou tentar explicar rapidamente como funciona o TDD com um exemplo prático e bem simples. Vou explicar seguindo a linha de raciocínio que normalmente se tem em tempo de programação pois a maneira de pensar no processo de desenvolvimento também faz parte do TDD.

Imagine que você está desenvolvendo um sistema no qual um usuário deve cadastrar seu endereço. O CEP digitado precisa ser validado para que tenha o formato 00000-000 e para isso será necessário desenvolver uma classe que faça a validação dos dados. Vamos definir a interface para esta classe de validação de dados:

public interface ValidadorDeDados {
    boolean isCepValido(String cep);
}

A partir deste ponto já temos o comportamento do nosso validador claramente definido: dada uma String contendo o valor de um CEP ele retornará verdadeiro se o CEP for válido e falso caso contrário. Por exemplo, se o validador receber uma String “teste” ou “” obviamente deverá retornar falso. Por outro lado se ele receber uma String “00000-000″ ou “12345-123″ deverá retornar verdadeiro.

Então já podemos desenvolver uma classe de teste que faça estas verificações e mais algumas outras pertinentes. Vou utilizar para os testes o framework JUnit que é o framework de testes unitários Java mais popular do mercado.

public class ValidadorDeDadosTest extends TestCase {
    private ValidadorDeDados validador = null; // instância de validador de dados para o teste
 
    public void testIsCepValido() {
        assertFalse("retorno deve ser FALSE", validador.isCepValido(null));
        assertFalse("retorno deve ser FALSE", validador.isCepValido(""));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("iodfjodfd"));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("03490340"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("20202-020"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("00000-000"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("99999-999"));
    }
}

Para quem não conhece o JUnit, o método assertFalse checa se o retorno da execução retornou falso e o método assertTrue checa se o retorno da execução retornou verdadeiro. Em todos os casos que o assertTrue foi utilizado o validador deverá retornar verdadeiro e o oposto deverá acontecer para os assertFalse. Se isto não acontecer, significa que tem alguma coisa errada.

Além disso colocamos uma pequena mensagem explicando o que esperamos que aconteça na execução do método. Isso é util para que outros desenvolvedores da equipe possam entender com facilidade o que você programou e está esperando que aconteça nos seus testes, bem como para deixar as mensagens de erro mais explicativas.

Só para não deixar dúvida nenhuma, vamos ler uma das linhas de teste:

assertFalse("retorno deve ser FALSE", validador.isCepValido(""));

Que é: Ao executar a validação do CEP “”, certifique-se que ele retornará FALSO.

Então vamos executar o teste para ver o que vai acontecer:

TDD 1

Ele falhou com NullPointerException porque não há uma implementação de validador, desenvolvemos somente a interface. No teste unitário o validador está setado como null.

Sendo assim, vamos desenvolver a primeira implementação de validador:

public class ValidadorDeDadosImpl implements ValidadorDeDados {
    public boolean isCepValido(String cep) {
        return false;
    }
}

Além disso é necessário alterar a classe de teste para utilizar esta implementação de validador de dados que desenvolvemos.

public class ValidadorDeDadosTest extends TestCase {
    private ValidadorDeDados validador = new ValidadorDeDadosImpl(); // agora o validador não é mais null
 
    public void testIsCepValido() {
        assertFalse("retorno deve ser FALSE", validador.isCepValido(null));
        assertFalse("retorno deve ser FALSE", validador.isCepValido(""));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("iodfjodfd"));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("03490340"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("20202-020"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("00000-000"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("99999-999"));
    }
}

Agora o teste já está rodando, o resultado foi bem diferente. Antes estava sendo lançada uma exception porque a implementação do validador de dados sequer existia. Agora o que acontece é que temos um problema na implementação do validador e o teste acusou isso:

TDD 2

Veja a implementação do validador de dador e repare que independente da String passada para o método ele retorna falso, ou seja, está errado. Vamos corrigir essa implementação:

public class ValidadorDeDadosImpl implements ValidadorDeDados {
    public boolean isCepValido(String cep) {
        if ((cep == null) || (cep.length() != 9) || cep.charAt(5) != '-') {
                return false;
        }
        return true;
    }
}

E executando novamente os testes podemos verificar que agora todos estão passando:

TDD 3

Desenvolvimento finalizado? Nada disso. Navegando pelo sistema e fazendo outros testes manuais descobrimos que é possível entrar com um CEP com letras tipo ABCDE-FGH. Se analisarmos a implementação do método veremos que isso realmente é possível. Não há nenhuma verificação que impeça isto.

Mas caramba, os testes não passaram? É verdade, os testes ainda estão passando. Acabamos de descobrir um bug.

Quando um bug é descoberto ou é reportado para a equipe de desenvolvimento, a primeira coisa a se fazer é escrever um teste para comprovar a existência do bug. Vamos então complementar a nossa classe de teste:

public class ValidadorDeDadosTest extends TestCase {
    private ValidadorDeDados validador = new ValidadorDeDadosImpl();
 
    public void testIsCepValido() {
        assertFalse("retorno deve ser FALSE", validador.isCepValido(null));
        assertFalse("retorno deve ser FALSE", validador.isCepValido(""));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("iodfjodfd"));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("03490340"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("20202-020"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("00000-000"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("99999-999"));
    }
 
    public void testIsCepValidoComLetras() {
        assertFalse("retorno deve ser FALSE", validador.isCepValido("AAAAA-AAA"));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("A2AA1-333"));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("x2334-567"));
    }
}

Executando os testes novamente vemos que o teste que acabamos de escrever falhou. Ao entrar com este CEP o validador deveria retornar falso pois é um CEP inválido mas ele está retornando verdadeiro. Muito bem, o bug está comprovado:

TDD 4

Repare que somente o teste novo está falhando, os testes antigos estão passando normalmente (em verde).

Com os testes prontos já podemos fazer a correção na implementação:

public class ValidadorDeDadosImpl implements ValidadorDeDados {
    public boolean isCepValido(String cep) {
        if ((cep == null) || (cep.length() != 9) || cep.charAt(5) != '-') {
            return false;
        }
        for (int i = 0; i < cep.length(); i++) {
            if (i != 5) {
                char posicao = cep.charAt(i);
                if (!Character.isDigit(posicao)) {
                    return false;
                }
            }
        }
        return true;
    }
}

E corrigida a implementação, vamos executar os testes novamente para verificar se o bug foi corrigido:

TDD 5

Agora sim tudo funcionando.

Podemos perceber como é fácil implementar funcionalidades e corrigir bugs com TDD. Alguns pontos fortes que merecem destaque:

1) Qualquer tipo de implementação por mais complexa que seja será suportada pelos testes e com isso você programa com mais confiança. Dado um comportamento do método que será definido antes do desenvolvimento você pode executar os testes inúmeras vezes até que eles passem. E quando eles passam você tem certeza absoluta de que o que você fez está efetivamente funcionando.

2) TDD facilita o refactoring: depois de cada reescrita de código ou qualquer tipo de alteração, especialmente em códigos que você não conhece bem porque foram feitos por outros membros da equipe, você pode rodar os testes da aplicação inteira afim de garantir que você não está quebrando nenhuma funcionalidade. Alguns sistemas são tão podres que dependendo do lugar que você mexe quebra tudo. Os testes te ajudam a não fazer isso.

3) Mesmo que seja um pouco mais demorado escrever testes ao desenvolver, com esta prática você praticamente não encontra bugs em produção e quando encontra eles podem ser corrigidos rapidamente e com confiança. Então no final das contas você GANHA tempo. E o melhor de tudo é que você programador não precisa ficar pisando em ovos e sem dormir porque mexeu na aplicação. Algumas aplicações são tão difĩceis de serem alteradas (porque são mal programadas) que você vai para casa e dorme com o celular do lado porque tem certeza que ele vai tocar porque deu pau no sistema!

Então, preserve seus cabelos e sua saúde: programe com qualidade! ;)

Download do código fonte.