JUnit Sample

TDD com JUnit
S E M I N Á R I O D E T E S T E S - E N G E N H A R I A D E S O F T WA R E
I N S T I T U TO D E E N G E N H A R I A 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 {
@Test
public 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
@Test
public void emptyTreeIsEmptyTest() {
assertTrue(emptyTree.isEmpty());
}
@Test
public void emptyTreeIsEmptyTest() {
assertEquals(true, emptyTree.isEmpty());
}

Padrões com JUnit
Coloque parâmetros de asserção na ordem expected, e então actual
@Test
public void addTest() {
BinaryTree expected = new BinaryTree();
...
assertEquals(expected, populatedTree);
}
@Test
public 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);
}
@Test
public 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.

JUnit Sample

Mais conteúdo relacionado

Mais procurados (20)

Destaque (13)

Semelhante a JUnit Sample (20)

Último (11)

JUnit Sample

Notas do Editor