SlideShare uma empresa Scribd logo
1 de 30
TDD
Test Driven Development
{
“Nome” : “Guilherme Botossi”,
“Profissão” : “Software Engineer”,
“Empresa” : “Creditas”
“Mercados” : [
“Fiscal”,
“Varejista”,
“Financeiro”,
“Educacional”,
“Pesquisa Cientifica”
],
“Redes_Sociais” : {
“Github”: “@guilhermebotossi”,
“Linkedin” : “@guilhermebotossi”,
“Instagram” : “@guilhermebotossi”
}
}
O que é TDD?
● Test Driven Development.
● Metodologia de desenvolvimento baseado em testes.
● Os testes unitários são escritos antes da funcionalidade.
Tipos de testes e distribuição:
CustoeComplexidade
O que é Teste Unitario?
Um teste unitário(de uma unidade) é o teste da menor parte
testável de um programa.
A unidade pode ser uma instrução, método, classe,
funcionalidade e etc.
Depende muito do que é a menor parte que seu software
pode ser testado.
Cada teste deve ser responsável por testar apenas um
comportamento
O Teste unitário deve ser (F.I.R.S.T.)
● Fast ⇒ Rápido;
● Independent ⇒ Independente;
● Repeatable ⇒ Repetitivo;
● Self-Verifiable ⇒ Auto-Verificável;
● Timily ⇒ Escrito no momento certo;
O que é Teste de Integração?
É o teste utilizando os recursos reais sem assistência de
test doubles, ou seja ele garante que tudo funciona
conforme testado.
Se eu tenho testes unitários, por que eu preciso de
testes de Integração?
Como Funciona
As 3 Leis do TDD
O desenvolvimento deve ser orientado por essas 3 leis:
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures
are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit
test.
Essas 3 leis em resumo fazem alusão ao uso de “Baby Steps”.
Robert C. Martin
aka Uncle Bob
Ciclo de Desenvolvimento de Testes Unitários
1 - RED - Erro nos teste;
2 - GREEN - Corrigir o erro no teste ou
corrigir o teste, da maneira mais fácil
possível ;
3 - REFACTOR - Limpar a casa, uma vez
que seu teste passou, agora você pode
pensar na melhor maneira de fazer;
Formato do Teste
Temos os 3 A’s :
● Arrange - É a preparação, seja de ambiente, variáveis, banco de dados, test
doubles e etc. Tudo aquilo que o teste irá utilizar.
● Act - Realizamos a chamada do SUT(System Under Test)
● Assert - É o momento de verificarmos se o teste trouxe os resultados
esperados.
Vantagens
● Evita future proofing(?)
● Garante consistência
● Evita desperdícios
● Refatoração em ambiente seguro
● Os testes são uma documentação
● Reduz esforços de retrabalho
Custo de correção de falhas
Desvantagens
● Tempo de desenvolvimento*
● Testes devem ser mantidos
● Deve ser um esforço de time
● Difícil ser aplicado em código legados
● No início tem custo alto no desenvolvimento
● Refatorações, requerem também a refatoração dos testes
O que ele não garante?
● Código livre de bugs
● Qualidade
● Ausência de Erros
Test Doubles
Dummy
● São Placeholders, geralmente eles são usados apenas para preencher listas
de parâmetros.
● Poderia ser substituido por Null
● São objetos que não interagem diretamente com o SUT
● O conteúdo não é relevante, mas o objeto é obrigatório
@Test
public void addCustomerTest() {
//método privado no teste pra criar um customer qualquer
//Customer customer = createDummyCustomer();
//Ou
Customer dummy = mock(Customer.class);
AddressBook addressBook = new AddressBook();
addressBook.addCustomer(customer);
assertEquals(1, addressBook.getNumberOfCustomers());
}
Stub
● Fornecem respostas pré configuradas às chamadas feitas durante o teste.
● Podemos usar para testar o caminho feliz e os casos com exceção
public class AcceptingAuthorizerStub implements Authorizer {
public Boolean authorize(String username, String password) {
return true;
}
}
EntityManager entityManager = mock(EntityManager.class);
when(entityManager.find(Customer.class,1L)).thenReturn(sampleCustomer);
Spy
● Spies são Stubs que registram informações de suas iterações.
● Podendo ou não ser a chamada do método real
@Test
public void whenStubASpy_thenStubbed() {
List<String> list = new ArrayList<String>();
List<String> spyList = Mockito.spy(list);
assertEquals(0, spyList.size());
Mockito.doReturn(100).when(spyList).size();
assertEquals(100, spyList.size());
}
@Test
public void whenSpyingOnList_thenCorrect() {
List<String> list = new ArrayList<String>();
List<String> spyList = Mockito.spy(list);
spyList.add("one");
spyList.add("two");
Mockito.verify(spyList).add("one");
Mockito.verify(spyList).add("two");
assertEquals(2, spyList.size());
}
Mock
● Mocks são objetos configurados, onde define-se o comportamento das
chamadas esperadas durante o teste.
● Podem lançar uma exceção se receberem uma chamada que não
configurada
● Permite verificação dos comportamentos configurados
UUIDProvider uuidProvider = mock(UUIDProvider.class)
when(uuidProvider.isValid(uuid)).thenReturn(true);
UUID id = UUID.fromString(uuid);
when(uuidProvider.fromString(str)).thenReturn(id);
verify(uuidProvider).isValid(str);
verify(uuidProvider).fromString(str);
Fake
● É uma implementação real, voltada para os testes e que não será usada em
produção
● Tem um comportamento voltado regras de negócio
● Podem ser extremamente complexos
● Normalmente representam um serviço externo, tal qual um banco de dado,
ou um sistema de autenticação.
public class AcceptingAuthorizerFake implements Authorizer {
public Boolean authorize(String username, String password) {
return username.equals("Bob");
}
}
Test Doubles
Escolas de TDD
Classicist (Detroit)
● Bottom-up / Middle-out
● Teste da API pública
● Avanço através de pequenos incrementos
● Liberdade para refatorações agressivas na
implementação
● Chances de criar um YAGNI
● Testes Superficiais, foco no resultado
● Teste de Regressão em uma única suíte
● Testa estado
Mockist (London)
● Top-down
● Teste de todas as camadas
● Alto acoplamento entre testes e
implementação
● Reescrever ao invés de re-fatorar
● Design Limpo e minimalista
● Grande quantidade de test doubles
● Teste regressão depende de mais de uma
suíte
● Testa Comportamento
System Under Test(SUT)
public BoletoVO listById(String id) {
if(uuidProvider.isValid(id)) {
UUID uuid = uuidProvider.fromString(id);
Optional<Boleto> bo =
boletoRepository.findById(uuid);
if(bo.isPresent()) {
return boletoMapper.mapToVO(bo.get());
} else {
throw new BankslipRecordNotFoundException();
}
}
throw new InvalidUUIDFormatException();
}
@Test
public void listById_called_returnOK() {
String uuid = "8c9f029f-53d2-4f75-8cf5-
75a13c4046e3";
BoletoVO bvo =
boletoService.listById(uuid);
assertNotNull(bvo);
assertEquals(uuid, bvo.getId().toString());
@Autowired
private BoletoService boletoService;
@Autowired
@Qualifier(“fakeBoletoRepository”)
private BoletoRepository
boletoRepository;
Exemplo-Classicist
Exemplo-Mockist @Test
public void listById_called_returnOK() {
String uuid = "8c9f029f-53d2-4f75-8cf5-
75a13c4046e3";
when(uuidProvider.isValid(uuid)).thenReturn(true);
UUID id = UUID.fromString(uuid);
when(uuidProvider.fromString(str)).thenReturn(id);
Boleto b = mock(Boleto.class);
Optional<Boleto> bo = Optional.of(b);
when(boletoRepository.findById(1)).thenReturn(bo);
BoletoVO bvo = mock(BoletoVO.class);
when(boletoMapper.mapToVO(b)).thenReturn(bvo);
BoletoVO bvo1 = boletoService.listById(str);
verify(uuidProvider).isValid(str);
verify(uuidProvider).fromString(str);
@Autowired
private BoletoService boletoService;
@MockBean
private BoletoRepository
boletoRepository;
@MockBean
private BoletoMapper boletoMapper;
@MockBean
private UUIDProvider uuidProvider;
Setup test
PERGUNTAS?
Referências
● https://blog.cleancoder.com/uncle-bob/2014/05/14/TheLittleMocker.html
● https://github.com/testdouble/contributing-tests/wiki/Detroit-school-TDD
● https://github.com/testdouble/contributing-tests/wiki/London-school-TDD
● http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
● http://codemanship.co.uk/parlezuml/blog/?postid=987
● http://thedevengers.com/tdd-triangulation/
● https://en.wikipedia.org/wiki/Test_double
● https://www.futurelearn.com/info/blog/stubs-mocks-spies-rspec
● https://pt.stackoverflow.com/questions/36745

Mais conteúdo relacionado

Mais procurados

Testando Aplicações Django: Quando, Como e Onde?
Testando Aplicações Django: Quando, Como e Onde?Testando Aplicações Django: Quando, Como e Onde?
Testando Aplicações Django: Quando, Como e Onde?Bernardo Fontes
 
Testes de unidade e TDD SoLiSC 2011
Testes de unidade e TDD SoLiSC 2011Testes de unidade e TDD SoLiSC 2011
Testes de unidade e TDD SoLiSC 2011Luís Cobucci
 
Aexo TI - Boas práticas de testes tdd
Aexo TI - Boas práticas de testes tddAexo TI - Boas práticas de testes tdd
Aexo TI - Boas práticas de testes tddCarlos Santana
 
Implementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel PimentelImplementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel PimentelManoel Pimentel Medeiros
 
Atividades de Teste e Cobertura de Código em Java
Atividades de Teste e Cobertura de Código em JavaAtividades de Teste e Cobertura de Código em Java
Atividades de Teste e Cobertura de Código em Javaaceiro
 
Teste unitário
Teste unitárioTeste unitário
Teste unitáriodist_bp
 
Testes de Unidade - Unidade II
Testes de Unidade - Unidade IITestes de Unidade - Unidade II
Testes de Unidade - Unidade IIJoão Lourenço
 
Programação defensiva
Programação defensivaProgramação defensiva
Programação defensivaKayo Rayner
 
Introdução a testes automatizados
Introdução a testes automatizadosIntrodução a testes automatizados
Introdução a testes automatizadosThiago Ghisi
 
O que você precisa saber sobre testes unitários
O que você precisa saber sobre testes unitáriosO que você precisa saber sobre testes unitários
O que você precisa saber sobre testes unitáriosFilipe M. Silva
 
PHP & Segurança: Blindando Aplicações Web - Rafael Jaques - Tchelinux Bento G...
PHP & Segurança: Blindando Aplicações Web - Rafael Jaques - Tchelinux Bento G...PHP & Segurança: Blindando Aplicações Web - Rafael Jaques - Tchelinux Bento G...
PHP & Segurança: Blindando Aplicações Web - Rafael Jaques - Tchelinux Bento G...Tchelinux
 
Testes Automatizados de Software
Testes Automatizados de SoftwareTestes Automatizados de Software
Testes Automatizados de SoftwareMaurício Aniche
 
Treinamento Testes Unitários - parte 1
Treinamento Testes Unitários - parte 1Treinamento Testes Unitários - parte 1
Treinamento Testes Unitários - parte 1Diego Pacheco
 

Mais procurados (20)

Introdução a tdd
Introdução a tddIntrodução a tdd
Introdução a tdd
 
TDD com Python
TDD com PythonTDD com Python
TDD com Python
 
Testando Aplicações Django: Quando, Como e Onde?
Testando Aplicações Django: Quando, Como e Onde?Testando Aplicações Django: Quando, Como e Onde?
Testando Aplicações Django: Quando, Como e Onde?
 
Testes de Sofware
Testes de SofwareTestes de Sofware
Testes de Sofware
 
Palestra Testes De Unidade Com JUnit
Palestra Testes De Unidade Com JUnitPalestra Testes De Unidade Com JUnit
Palestra Testes De Unidade Com JUnit
 
Testes de unidade e TDD SoLiSC 2011
Testes de unidade e TDD SoLiSC 2011Testes de unidade e TDD SoLiSC 2011
Testes de unidade e TDD SoLiSC 2011
 
Aexo TI - Boas práticas de testes tdd
Aexo TI - Boas práticas de testes tddAexo TI - Boas práticas de testes tdd
Aexo TI - Boas práticas de testes tdd
 
Implementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel PimentelImplementando Testes Unitários em Java - Manoel Pimentel
Implementando Testes Unitários em Java - Manoel Pimentel
 
Atividades de Teste e Cobertura de Código em Java
Atividades de Teste e Cobertura de Código em JavaAtividades de Teste e Cobertura de Código em Java
Atividades de Teste e Cobertura de Código em Java
 
Teste unitário
Teste unitárioTeste unitário
Teste unitário
 
Testes Unitários
Testes UnitáriosTestes Unitários
Testes Unitários
 
Testes de Unidade - Unidade II
Testes de Unidade - Unidade IITestes de Unidade - Unidade II
Testes de Unidade - Unidade II
 
Refatoração
RefatoraçãoRefatoração
Refatoração
 
Programação defensiva
Programação defensivaProgramação defensiva
Programação defensiva
 
Introdução a testes automatizados
Introdução a testes automatizadosIntrodução a testes automatizados
Introdução a testes automatizados
 
O que você precisa saber sobre testes unitários
O que você precisa saber sobre testes unitáriosO que você precisa saber sobre testes unitários
O que você precisa saber sobre testes unitários
 
PHP & Segurança: Blindando Aplicações Web - Rafael Jaques - Tchelinux Bento G...
PHP & Segurança: Blindando Aplicações Web - Rafael Jaques - Tchelinux Bento G...PHP & Segurança: Blindando Aplicações Web - Rafael Jaques - Tchelinux Bento G...
PHP & Segurança: Blindando Aplicações Web - Rafael Jaques - Tchelinux Bento G...
 
Testes de Sistema
Testes de SistemaTestes de Sistema
Testes de Sistema
 
Testes Automatizados de Software
Testes Automatizados de SoftwareTestes Automatizados de Software
Testes Automatizados de Software
 
Treinamento Testes Unitários - parte 1
Treinamento Testes Unitários - parte 1Treinamento Testes Unitários - parte 1
Treinamento Testes Unitários - parte 1
 

Semelhante a TDD: Test Driven Development e seus principais conceitos

Paletra sobre TDD, ocorrida no #DevDojo
Paletra sobre TDD, ocorrida no #DevDojoPaletra sobre TDD, ocorrida no #DevDojo
Paletra sobre TDD, ocorrida no #DevDojoflavio1110
 
Testes de Unidade com Junit
Testes de Unidade com JunitTestes de Unidade com Junit
Testes de Unidade com Junitcejug
 
Teste de Integração - Unidade III
Teste de Integração - Unidade IIITeste de Integração - Unidade III
Teste de Integração - Unidade IIIJoão Lourenço
 
Android DevConference - Indo além com automação de testes de apps Android
Android DevConference - Indo além com automação de testes de apps AndroidAndroid DevConference - Indo além com automação de testes de apps Android
Android DevConference - Indo além com automação de testes de apps AndroidiMasters
 
Indo além com Automação de Testes de Apps Android
Indo além com Automação de Testes de Apps AndroidIndo além com Automação de Testes de Apps Android
Indo além com Automação de Testes de Apps AndroidEduardo Carrara de Araujo
 
Dubles de Testes - Na Pratica
Dubles de Testes - Na PraticaDubles de Testes - Na Pratica
Dubles de Testes - Na PraticaIsmael
 
TDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no AndroidTDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no Androidtdc-globalcode
 
TDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no AndroidTDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no Androidtdc-globalcode
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de softwareRondinelli Mesquita
 
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...Claudinei Brito Junior
 
Palestra Testes Unidade Com JUnit
Palestra Testes Unidade Com JUnitPalestra Testes Unidade Com JUnit
Palestra Testes Unidade Com JUnitRobinson Castilho
 
Testes, engenharia de Software, teste de Software
Testes, engenharia de Software, teste de SoftwareTestes, engenharia de Software, teste de Software
Testes, engenharia de Software, teste de SoftwareSilas Gonçalves
 

Semelhante a TDD: Test Driven Development e seus principais conceitos (20)

Paletra sobre TDD, ocorrida no #DevDojo
Paletra sobre TDD, ocorrida no #DevDojoPaletra sobre TDD, ocorrida no #DevDojo
Paletra sobre TDD, ocorrida no #DevDojo
 
Testes de Unidade com Junit
Testes de Unidade com JunitTestes de Unidade com Junit
Testes de Unidade com Junit
 
Test driven development
Test driven developmentTest driven development
Test driven development
 
Teste de Integração - Unidade III
Teste de Integração - Unidade IIITeste de Integração - Unidade III
Teste de Integração - Unidade III
 
Android DevConference - Indo além com automação de testes de apps Android
Android DevConference - Indo além com automação de testes de apps AndroidAndroid DevConference - Indo além com automação de testes de apps Android
Android DevConference - Indo além com automação de testes de apps Android
 
Indo além com Automação de Testes de Apps Android
Indo além com Automação de Testes de Apps AndroidIndo além com Automação de Testes de Apps Android
Indo além com Automação de Testes de Apps Android
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
Apresentação testes white box
Apresentação testes white boxApresentação testes white box
Apresentação testes white box
 
Unit Testing
Unit TestingUnit Testing
Unit Testing
 
Dubles de Testes - Na Pratica
Dubles de Testes - Na PraticaDubles de Testes - Na Pratica
Dubles de Testes - Na Pratica
 
Testes de Unidade com JUnit
Testes de Unidade com JUnitTestes de Unidade com JUnit
Testes de Unidade com JUnit
 
Java 12
Java 12Java 12
Java 12
 
JUnit Sample
JUnit SampleJUnit Sample
JUnit Sample
 
TDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no AndroidTDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no Android
 
TDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no AndroidTDC2016POA | Trilha Android - Testes no Android
TDC2016POA | Trilha Android - Testes no Android
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
 
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
 
Palestra Testes Unidade Com JUnit
Palestra Testes Unidade Com JUnitPalestra Testes Unidade Com JUnit
Palestra Testes Unidade Com JUnit
 
Testes, engenharia de Software, teste de Software
Testes, engenharia de Software, teste de SoftwareTestes, engenharia de Software, teste de Software
Testes, engenharia de Software, teste de Software
 
Robotium_Sikuli
Robotium_SikuliRobotium_Sikuli
Robotium_Sikuli
 

TDD: Test Driven Development e seus principais conceitos

  • 2. { “Nome” : “Guilherme Botossi”, “Profissão” : “Software Engineer”, “Empresa” : “Creditas” “Mercados” : [ “Fiscal”, “Varejista”, “Financeiro”, “Educacional”, “Pesquisa Cientifica” ], “Redes_Sociais” : { “Github”: “@guilhermebotossi”, “Linkedin” : “@guilhermebotossi”, “Instagram” : “@guilhermebotossi” } }
  • 3. O que é TDD? ● Test Driven Development. ● Metodologia de desenvolvimento baseado em testes. ● Os testes unitários são escritos antes da funcionalidade.
  • 4. Tipos de testes e distribuição: CustoeComplexidade
  • 5. O que é Teste Unitario? Um teste unitário(de uma unidade) é o teste da menor parte testável de um programa. A unidade pode ser uma instrução, método, classe, funcionalidade e etc. Depende muito do que é a menor parte que seu software pode ser testado. Cada teste deve ser responsável por testar apenas um comportamento
  • 6. O Teste unitário deve ser (F.I.R.S.T.) ● Fast ⇒ Rápido; ● Independent ⇒ Independente; ● Repeatable ⇒ Repetitivo; ● Self-Verifiable ⇒ Auto-Verificável; ● Timily ⇒ Escrito no momento certo;
  • 7. O que é Teste de Integração? É o teste utilizando os recursos reais sem assistência de test doubles, ou seja ele garante que tudo funciona conforme testado.
  • 8. Se eu tenho testes unitários, por que eu preciso de testes de Integração?
  • 9. Como Funciona As 3 Leis do TDD O desenvolvimento deve ser orientado por essas 3 leis: 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. Essas 3 leis em resumo fazem alusão ao uso de “Baby Steps”. Robert C. Martin aka Uncle Bob
  • 10. Ciclo de Desenvolvimento de Testes Unitários 1 - RED - Erro nos teste; 2 - GREEN - Corrigir o erro no teste ou corrigir o teste, da maneira mais fácil possível ; 3 - REFACTOR - Limpar a casa, uma vez que seu teste passou, agora você pode pensar na melhor maneira de fazer;
  • 11. Formato do Teste Temos os 3 A’s : ● Arrange - É a preparação, seja de ambiente, variáveis, banco de dados, test doubles e etc. Tudo aquilo que o teste irá utilizar. ● Act - Realizamos a chamada do SUT(System Under Test) ● Assert - É o momento de verificarmos se o teste trouxe os resultados esperados.
  • 12. Vantagens ● Evita future proofing(?) ● Garante consistência ● Evita desperdícios ● Refatoração em ambiente seguro ● Os testes são uma documentação ● Reduz esforços de retrabalho
  • 13. Custo de correção de falhas
  • 14. Desvantagens ● Tempo de desenvolvimento* ● Testes devem ser mantidos ● Deve ser um esforço de time ● Difícil ser aplicado em código legados ● No início tem custo alto no desenvolvimento ● Refatorações, requerem também a refatoração dos testes
  • 15. O que ele não garante? ● Código livre de bugs ● Qualidade ● Ausência de Erros
  • 17. Dummy ● São Placeholders, geralmente eles são usados apenas para preencher listas de parâmetros. ● Poderia ser substituido por Null ● São objetos que não interagem diretamente com o SUT ● O conteúdo não é relevante, mas o objeto é obrigatório @Test public void addCustomerTest() { //método privado no teste pra criar um customer qualquer //Customer customer = createDummyCustomer(); //Ou Customer dummy = mock(Customer.class); AddressBook addressBook = new AddressBook(); addressBook.addCustomer(customer); assertEquals(1, addressBook.getNumberOfCustomers()); }
  • 18. Stub ● Fornecem respostas pré configuradas às chamadas feitas durante o teste. ● Podemos usar para testar o caminho feliz e os casos com exceção public class AcceptingAuthorizerStub implements Authorizer { public Boolean authorize(String username, String password) { return true; } } EntityManager entityManager = mock(EntityManager.class); when(entityManager.find(Customer.class,1L)).thenReturn(sampleCustomer);
  • 19. Spy ● Spies são Stubs que registram informações de suas iterações. ● Podendo ou não ser a chamada do método real @Test public void whenStubASpy_thenStubbed() { List<String> list = new ArrayList<String>(); List<String> spyList = Mockito.spy(list); assertEquals(0, spyList.size()); Mockito.doReturn(100).when(spyList).size(); assertEquals(100, spyList.size()); } @Test public void whenSpyingOnList_thenCorrect() { List<String> list = new ArrayList<String>(); List<String> spyList = Mockito.spy(list); spyList.add("one"); spyList.add("two"); Mockito.verify(spyList).add("one"); Mockito.verify(spyList).add("two"); assertEquals(2, spyList.size()); }
  • 20. Mock ● Mocks são objetos configurados, onde define-se o comportamento das chamadas esperadas durante o teste. ● Podem lançar uma exceção se receberem uma chamada que não configurada ● Permite verificação dos comportamentos configurados UUIDProvider uuidProvider = mock(UUIDProvider.class) when(uuidProvider.isValid(uuid)).thenReturn(true); UUID id = UUID.fromString(uuid); when(uuidProvider.fromString(str)).thenReturn(id); verify(uuidProvider).isValid(str); verify(uuidProvider).fromString(str);
  • 21. Fake ● É uma implementação real, voltada para os testes e que não será usada em produção ● Tem um comportamento voltado regras de negócio ● Podem ser extremamente complexos ● Normalmente representam um serviço externo, tal qual um banco de dado, ou um sistema de autenticação. public class AcceptingAuthorizerFake implements Authorizer { public Boolean authorize(String username, String password) { return username.equals("Bob"); } }
  • 23. Escolas de TDD Classicist (Detroit) ● Bottom-up / Middle-out ● Teste da API pública ● Avanço através de pequenos incrementos ● Liberdade para refatorações agressivas na implementação ● Chances de criar um YAGNI ● Testes Superficiais, foco no resultado ● Teste de Regressão em uma única suíte ● Testa estado Mockist (London) ● Top-down ● Teste de todas as camadas ● Alto acoplamento entre testes e implementação ● Reescrever ao invés de re-fatorar ● Design Limpo e minimalista ● Grande quantidade de test doubles ● Teste regressão depende de mais de uma suíte ● Testa Comportamento
  • 24. System Under Test(SUT) public BoletoVO listById(String id) { if(uuidProvider.isValid(id)) { UUID uuid = uuidProvider.fromString(id); Optional<Boleto> bo = boletoRepository.findById(uuid); if(bo.isPresent()) { return boletoMapper.mapToVO(bo.get()); } else { throw new BankslipRecordNotFoundException(); } } throw new InvalidUUIDFormatException(); }
  • 25. @Test public void listById_called_returnOK() { String uuid = "8c9f029f-53d2-4f75-8cf5- 75a13c4046e3"; BoletoVO bvo = boletoService.listById(uuid); assertNotNull(bvo); assertEquals(uuid, bvo.getId().toString()); @Autowired private BoletoService boletoService; @Autowired @Qualifier(“fakeBoletoRepository”) private BoletoRepository boletoRepository; Exemplo-Classicist
  • 26. Exemplo-Mockist @Test public void listById_called_returnOK() { String uuid = "8c9f029f-53d2-4f75-8cf5- 75a13c4046e3"; when(uuidProvider.isValid(uuid)).thenReturn(true); UUID id = UUID.fromString(uuid); when(uuidProvider.fromString(str)).thenReturn(id); Boleto b = mock(Boleto.class); Optional<Boleto> bo = Optional.of(b); when(boletoRepository.findById(1)).thenReturn(bo); BoletoVO bvo = mock(BoletoVO.class); when(boletoMapper.mapToVO(b)).thenReturn(bvo); BoletoVO bvo1 = boletoService.listById(str); verify(uuidProvider).isValid(str); verify(uuidProvider).fromString(str); @Autowired private BoletoService boletoService; @MockBean private BoletoRepository boletoRepository; @MockBean private BoletoMapper boletoMapper; @MockBean private UUIDProvider uuidProvider; Setup test
  • 27.
  • 28.
  • 30. Referências ● https://blog.cleancoder.com/uncle-bob/2014/05/14/TheLittleMocker.html ● https://github.com/testdouble/contributing-tests/wiki/Detroit-school-TDD ● https://github.com/testdouble/contributing-tests/wiki/London-school-TDD ● http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd ● http://codemanship.co.uk/parlezuml/blog/?postid=987 ● http://thedevengers.com/tdd-triangulation/ ● https://en.wikipedia.org/wiki/Test_double ● https://www.futurelearn.com/info/blog/stubs-mocks-spies-rspec ● https://pt.stackoverflow.com/questions/36745

Notas do Editor

  1. http://tdd.caelum.com.br/ https://martinfowler.com/articles/mocksArentStubs.html https://www.devmedia.com.br/test-driven-development-tdd-simples-e-pratico/18533
  2. https://medium.com/trainingcenter/testes-unit%C3%A1rios-mocks-stubs-spies-e-todas-essas-palavras-dif%C3%ADceis-f2765ac87cc8 https://klauslaube.com.br/2015/06/29/os-testes-e-os-dubles-parte-2.html https://martinfowler.com/articles/mocksArentStubs.html https://martinfowler.com/bliki/TestDouble.html https://hipsters.tech/testes-automatizados-hipsters-51/
  3. https://agilewarrior.wordpress.com/2015/04/18/classical-vs-mockist-testing/ https://stackoverflow.com/questions/3464629/what-does-regression-test-mean