TDD com JUnitS E M I N Á R IO D E T E ST E S - E N G E N H A R I A D E S O FT WA R E

I N S T I T U T O D E E N GE N H A R IA E T E C N O LO G I A – I E T

C E N T R O U N I V E R S I TÁ R I O D E B E LO H O R I Z O N T E – U N I B H

D E Z E M B R O D E 2 0 1 6

Integrantes Bruno Meirelles Souza

Deborah Moreira Bertoni da Silva

Guilherme Alberto de Moraes

Hebert Reis Júnior

Lucas Maia Veríssimo

Michael Vinicius de Souza Gonçalves

CIC4BN-ESA

Test Driven Development Prática de desenvolvimento no qual a escrita dos códigos de testes ocorrem antes da escrita do código funcional.

Atividades de Teste, Codificação e Refatoração .

Permite conformidade e objetividade no código desenvolvido.

JUnit Framework para escrita de testes repetitivos em Java.

É um exemplo da arquitetura xUnit de frameworks de teste da unidade.

Possui dependência em Maven.

Exemplo No exemplo vemos uma classe Operations sendo testada pela OperationsTest

public class OperationsTest {@Testpublic void sumTest() {

int expected = 5;int actual =

Operations.sum(2, 3);

assertEquals(expected, actual);}

}

public class Operations {public static int sum(int

a, int b) {return a + b;

}}

Aplicação Desenvolvimento de árvore binaria testada com JUnit.

Etapas de desenvolvimento:◦ Criação do projeto Maven◦ Geração de assinaturas do código◦ Confecção dos testes◦ Confecção do código

Criação do projeto Maven

Permite gestão de dependências de um projeto.

Tem por padrão um diretório dedicado a Classes e testes.

Geração de assinaturas do código

Etapa de definição de classes e métodos que serão consumidos

Os métodos ainda não implementam as regras, apenas definem suas funções.

Confecção dos testes Os testes são então gerados no devido diretório.

As dependências são criadas no método assinado com a anotação @Before

Os testes são implementados nos métodos com a anotação @Test

Confecção dos testes O código deve ser gerado de uma forma simples e objetiva.

A partir desse momento, os testes devem ser todos aprovados.

Confecção do código O código deve ser gerado de uma forma simples e objetiva.

A partir desse momento, os testes devem ser todos aprovados.

Padrões com JUnit Use os métodos de asserção mais apropriados

@Testpublic void emptyTreeIsEmptyTest() {

assertTrue(emptyTree.isEmpty());}

@Testpublic void emptyTreeIsEmptyTest() {

assertEquals(true, emptyTree.isEmpty());}

Padrões com JUnit Coloque parâmetros de asserção na ordem expected, e então actual

@Testpublic void addTest() {BinaryTree expected = new BinaryTree();...assertEquals(expected, populatedTree);

}

@Testpublic void addTest() {BinaryTree expected = new BinaryTree();...assertEquals(populatedTree, expected);

}

Padrões com JUnit Não utilize blocos try-catch dentro dos testes, dê preferência para a clausula expected após o comentário @Test.

@Test(expected = IllegalArgumentException.class)public void invalidRemovalTest() throws IllegalArgumentException{

populatedTree.remove(10);}

@Testpublic void invalidRemovalTest() throws IllegalArgumentException{

boolean exp = false;try{populatedTree.remove(10);} catch (IllegalArgumentException e){exp = true;}assertTrue(exp);

}

Padrões com JUnit Tenha certeza que os testes estão no mesmo pacote do código, mas em diretórios separados.

Problemas comuns Erros Individuais:

◦ Não executar testes frequentemente◦ Muitos ensaios de uma só vez◦ Testes triviais

Erros em equipe:◦ Adoção parcial do TDD◦ Falta de manutenção do conjunto de testes◦ Conjunto de testes abandonado

Benefícios de TDD Segurança na correção de bugs

Segurança no Refactoring

Código mais limpo (redução de defeitos)

Código da aplicação mais flexível (menos acoplado)

Maior produtividade (redução de esforço)

Conclusões O TDD e os testes gerados dão feedback muito mais rápido sobre a qualidade do software

O TDD, como qualquer outra prática de Engenharia de Software não deve ser executado 100% do tempo

Design de classes melhor e mais flexível

Referências Agile Alliance. Definition. Agile Alliance All Rights Reserved. Web Development Company: 352 Inc. Disponível em: https://www.agilealliance.org/glossary/tdd/. Acesso em: 3 Dez 2016.

BLANEY, Kyle. Melhores práticas JUnit. Disponível em: http://www.kyleblaney.com/junit-best-practices/. Acesso em: 3 Dez 2016.

ANICHE, Maurício. Test-Driven Development. Abril/2014. Disponível em: http://tdd.caelum.com.br/. Acesso em: 3 Dez 2016.

ANICHE, Maurício. É “Test-Driven Design” e não “Design Done by Tests”. Dezembro/2010. Disponívle em: http://www.aniche.com.br/2010/12/eh-tdd-e-nao-ddt/. Acesso em: 3 Dez 2016.

GAMA, Alexandre. Test Driven Development: TDD simples e prático. Disponível em: http://www.devmedia.com.br/test-driven-development-tdd-simples-e-pratico/18533. Acesso em: 3 Dez 2016.

Dúvidas?