Este documento resume um seminário sobre desenvolvimento orientado a testes (TDD) usando a biblioteca JUnit em Java. Ele descreve os princípios do TDD, apresenta JUnit como um framework de teste popular e fornece um exemplo de como usar JUnit para testar uma árvore binária.

1. 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

2. 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

3. 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.

4. 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.

5. 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;
}
}

6. 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

7. 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.

8. 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.

9. 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

10. 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.

11. 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.

12. 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());
}

13. 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);
}

14. 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);
}

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

16. 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

17. 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)

18. 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

19. 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.

20. Dúvidas?