1 6 – Testes Unitários "Apenas duas coisas são infinitas: o universo e a estupidez humana. E eu não tenho certeza do primeiro.“ - Albert Einstein

2 Start Point Calculadora: (10 min)maior(int, int) soma(int...) subtrai(int, int) raiz(double) media(double ...) Ao terminar, crie um main para testar seu programa.

3

4 O que é “testar código”? É a coisa mais importante do desenvolvimentoSe seu código não funciona, ele não presta! Todos vocês já testam seus programas Você testa uma classe quando cria algumas instâncias dela no método main() Seu cliente testa seu software quando ele o utiliza (ele espera que você o tenha testado antes) O que são testes automáticos? São procedimentos que avaliam se um programa funciona como esperado, retornando respostas do tipo "sim" ou "não" Validam os requisitos de um sistema

5 Por que testar? Por que não?Como saber se o recurso funciona sem testar? Como saber se ainda funciona após refatoramento? Coragem para mudar - testes dão maior segurança Nós projetamos nosso código de modo a evitar retrabalho. Mas, já vimos que mudança é algo inerente no mundo do desenvolvimento de software Código testado pode ser alterado sem medo e é mais confiável Conseguimos identificar efeitos colaterais indesejados com mais facilidade Progresso - como saber quando o projeto está pronto Testes == requisitos 'executáveis' Testes de unidade devem ser executados o tempo todo Escreva os testes antes. Quando todos rodarem 100%, o projeto está concluído!

6 Testes de Unidade Testes de unidade são testes que testam apenas uma classe ou método, verificando se seu comportamento está de acordo com o desejado. Em testes de unidade, verificamos a funcionalidade da classe e/ou método em questão passando o mínimo possível por outras classes ou dependências do nosso sistema. Unidade é a menor parte testável de uma aplicação. Em uma linguagem de programação orientada a objetos como o Java, a menor unidade é um método.

7 O que é Junit? Junit é um framework de código aberto que nos permite escrever e executar testes para programas em Java, testes estes que podem ser facilmente repetidos A API Classes Test, TestCase, TestSuite, etc. oferecem a infraestrutura necessária para criar os testes Métodos assertTrue(), assertEquals(), etc. são usados para testar os resultados

8 Testar é uma boa prática, mas é chato; JUnit torna as coisas mais agradáveis, facilitandoA criação e execução automática de testes A apresentação dos resultados JUnit pode verificar se cada unidade de código funciona da forma esperada Ao utilizarmos System.out.println() é preciso ler e interpretar todo o output gerado para verificar se os testes foram bem sucedidos Junit permite agrupar e rodar vários testes ao mesmo tempo, e em caso de falha, mostra a causa em cada teste

9 Quando escrever testes?Antes de implementar Só escreve o novo código quando o teste automatizado estiver falhando Bons testes ajudam no projeto do sistema Escreva testes para trechos de programa que poderiam ser quebrados ou ter bugs Ex.: getters não precisam de teste... setters só precisam ser testado se tiver alguma validação do dado a ser atribuído.

10 Quando rodar os Testes? O mais frequente possível.Idealmente, sempre que você mudar seu código Assim você tem confiança de que suas alterações não quebrou nenhuma parte do programa Pelo menos uma vez por dia Existem vários programas que dão suporte a teste contínuo

11 Exemplo de um roteiro típicoCrie uma classe importando a biblioteca JUnit e a classe Assert (de modo estático) Para a classe Simple, o nome da classe de teste deveria ser SimpleTest

12 Exemplo de um roteiro típicoPara cada método xxx(args) a ser testado defina um método public void testXxx() no test case Simple: public boolean equals(Object o){...} SimpleTest: public void testEquals(){...}

13 Exemplo de um roteiro típicoTestFixture Um test fixture é importante quando se tem 2 ou mais testes que usam um conjunto de objetos comum; Test fixture evita duplicação de código desnecessária para inicializar e limpar os objetos em comum Os testes são isolados e portanto podem ser executados em ordem aleatória

14 Exemplo de um roteiro típicoTestFixture Para tanto, crie métodos “public void” e os anote com ou Ordem: Aleatória

15 Exemplo de um roteiro típicoTestFixture - Geralmente usado para desalocar recursos externos que foram alocados O que poderia acontecer se nesse exemplo não existisse Os testes gerariam “lixo” no seu computador; Poderia acontecer exceções ao se tentar criar novos arquivos com o mesmo path de um arquivo já existente Ainda

16 Class Assert Métodos estáticos para testar algumas condições ou afirmações (assert) Tipicamente começam com assert e nos permite especificar uma mensagem de erro, o valor esperado (expected) e o valor retornado (actual) Se o teste falhar, lança um AssertionException 

17 Class Assert

18 Cria a classe de testes Clica com o Botão direito do mouse sobre projeto: New  other Java  Junit  Junit Test Case

19 Cria a classe de testes Clica com o Botão direito do mouse sobre projeto: New  other Java  Junit  Junit Test Case Escolhe o nome da classe de teste, pacote onde deve salvá-la, métodos a serem etc.) Escolhe classe a ser testada Add biblioteca de Junit no projeto

20 Botão direito do mouse  Run as  Junit test

21 CalculadoraTest  Calculadora: (10 min) maior(int, int) soma(int...)subtrai(int, int) raiz(double) media(double ...)

22 Double é INEXATO! Antes de seguirmos... Façam o seguinte teste...O teste executa sem falhas?? Double é INEXATO!

23 Métodos sem retorno Provavelmente esse método tem um efeito colateralSe não tem retorno nem efeito colateral, ele não está fazendo nada Podemos verificar se o efeito colateral ocorreu como esperado: Ex: método add( )de Collections. Como testá-lo? Para casos mais complexos utilizamos MockObjects.

24 Métodos que lançam exceçãoQuando a exceção é esperada

25 Métodos que devem falhar o teste ao lançar uma exceçãoQuando a exceção não é esperada: Declare que lança a exceção (obrigatório para checked Exceptions), mas não a capture, nem ponha o expected =SomeException.class

26 Modificadores de acesso restritivoMétodos private e variáveis locais não podem ser testadas com Junit Dados devem ser pelo menos package-private ou protected Solução: Transformar métodos private em package-private Desvantagem: quebra ou redução do encapsulamento Classes de teste devem estar no mesmo pacote que as classes testadas para ter acesso Reflexão: JUnitX, Dp4j, etc. Se o método private tem baixa complexidade, testar os métodos públicos que o utilizam já aumenta o grau de confiabilidade de nosso software. Se ele for muito complexo, ele merecia estar em uma classe e ter modificador público.

27 Suíte de Testes

28 Cenário de TDD Test-Driven Development (TDD)Defina uma lista de tarefas a implementar. Escreva uma classe (test case) e implemente um método de teste para uma tarefa da lista. Rode o JUnit e certifique-se que o teste falha Implemente o código mais simples que rode o teste Crie classes, métodos, etc. para que código compile Código pode ser código feio, óbvio, mas deve rodar! Refatore o código para remover a implementação trivial Escreva mais um teste ou refine o teste existente Repita os passos 2 a 6 até implementar toda a lista

29 Implemente o método para passar no teste:Crie um caso de teste: Implemente o método para passar no teste: Crie outro caso de teste: Crie outra implementação que faça o teste passar!

30 Tarefa Implemente testes unitários para os exercícios 1, 2, 3 e 4 da Lista 1.

31 Referências http://junit.org/Notas de aula do professor Helder da Rocha – Testes de Unidade com JUnit