O documento discute Test-Driven Development (TDD) e fornece exemplos de casos de teste para uma tela de cadastro de usuário. TDD envolve escrever testes de unidade antes de escrever o código de produção para guiar o desenvolvimento e garantir que os requisitos sejam atendidos. Cada caso de teste deve ter um teste de unidade correspondente para validá-lo.

1. Community .com
Introdução ao
T D D
@CharlesFortes

2. Introdução ao
Test-Driven Development
.com
Cadastro de Usuário Cadastro de Usuário
Cadastro de Usuário
Cadastro de Usuário Cadastro de Usuário
Cadastro de Usuário Cadastro de Usuário
Cadastro de Usuário
@CharlesFortes

3. Introdução ao
Test-Driven Development
.com
• Meu sistema pode ter no máximo 6 usuários;
• Para poder cadastrar um usuário, deve-se estar logado no sistema e possuir
permissão específica para isto;
• Não podem haver dois logins iguais no sistema;
• A senha deve ter no mínimo 6 caracteres e não pode ter mais de 50 caracteres;
• Nome, Login e senha são campos obrigatórios;
@CharlesFortes

4. Introdução ao
Test-Driven Development
.com
O que é
Test-DrivenDevelopment ?
@CharlesFortes

5. Introdução ao
Test-Driven Development
.com
É Desenvolver Focado no Caso
de Testes, nas Especificações
@CharlesFortes

6. Introdução ao
Test-Driven Development
.com
WTF?
É Desenvolver Focado no Caso
de Testes, nas Especificações
@CharlesFortes

7. Introdução ao
Test-Driven Development
.com
Casos de Testes são condições aos quais o
software deverá ser submetido para que possa ser testado
quanto ao seu funcionamento adequado e verificando se ele
atende ao que foi solicitado
@CharlesFortes

8. Introdução ao
Test-Driven Development
.com
Entende-se que nossa tela de cadastro de usuário está
funcionando corretamente quando as seguintes condições estiverem
satisfeitas:
1. Logado no sistema e tendo permissão para cadastrar usuários, cadastrar um usuário  Incluir
corretamente, exibir mensagem de sucesso
2. Tentar inserir 7 usuário  O sistema não pode permitir, retornando uma exceção
3. Com 6 usuários cadastrados, remover um usuário e inserir um novo  Incluir corretamente, exibir
mensagem de sucesso
4. Tentar cadastrar um usuário sem estar logado no sistema  Não permitir, retornar exceção
5. Estando logado no sistema, tentar cadastrar um usuário sem ter permissão  Não permitir, retornar
exceção
6. Tentar cadastrar dois usuários com o mesmo nome  Não permitir, retornar uma exceção
7. Remover um usuário e cadastrar um novo com o mesmo nome
@CharlesFortes

9. Introdução ao
Test-Driven Development
.com
Entende-se que nossa tela de cadastro de usuário está
funcionando corretamente quando as seguintes condições estiverem
satisfeitas:
1. Tentar salvar um usuário com o login em branco  não permitir, retornar uma exceção
2. Tentar salvar um usuário com o nome em branco  não permitir, retornar uma exceção
3. Tentar cadastrar um usuário com senha em branco  não permitir, retornar uma exceção
4. Tentar cadastrar uma senha com 5 dígitos  não permitir, retornar uma exceção
5. Tentar cadastrar uma senha com 6 dígitos  Incluir corretamente, exibir mensagem de sucesso
6. Tentar cadastrar uma senha de 50 dígitos  Incluir corretamente, exibir mensagem de sucesso
7. Tentar cadastrar uma senha com 51 dígitos  não permitir, retornar uma exceção
@CharlesFortes

10. Introdução ao
Test-Driven Development
.com
Para cada um dos casos de testes apresentados anteriormente,
deve existir um teste de unidade que o valide de forma
absoluta.
@CharlesFortes

11. Introdução ao
Test-Driven Development
.com
WTF?
Para cada um dos casos de testes apresentados anteriormente,
deve existir um teste de unidade que o valide de forma
absoluta.
@CharlesFortes

12. Introdução ao
Test-Driven Development
.com
Segundo a Wikipédia
“Testes de unidade é um método pelo qual as unidades individuais do
código-fonte são testados para determinar se eles estão aptos
para o uso.
A unidade é a menor parte testável de um aplicativo. Na programação
procedural uma unidade pode ser uma função individual ou
procedimento. Na programação orientada a objeto uma unidade é
normalmente um método.”
@CharlesFortes

13. Introdução ao
Test-Driven Development
.com
Um teste de unidade, é um teste automatizado que testa
uma funcionalidade/aspecto/Requisito do sistema
i.e. Testar a capacidade do sistema de se permitir
cadastrar um usuário dentro dos moldes do
negócio
@CharlesFortes

14. Introdução ao
Test-Driven Development
.com
Testa
@CharlesFortes

15. Introdução ao
Test-Driven Development
.com
Teste de unidade deve ser executável independente dos dados
O teste de unidade deve conter tudo
o que o teste necessita, ele não pode depender de estados gerados por
outros testes, ele deve funcionar tão bem sendo executado sozinho como com todos os
demais
Teste de unidade sempre será usado como teste de regressão
@CharlesFortes

16. Introdução ao
Test-Driven Development
.com
Teste de unidade feito por fazer não tem valor
@CharlesFortes

17. Introdução ao
Test-Driven Development
.com
Não altere ou exclua testes para ter um novo. O teste só deve mudar
quando a funcionalidade mudar
Teste de unidade deve testar o Contrato, não teste nada além do contrato
@CharlesFortes

18. Introdução ao
Test-Driven Development
.com
No modelo tradicional de desenvolvimento, primeiro se cria o código, e
depois se implementam os testes necessários para seu funcionamento
Planeja >
Requisitos Teste de Aceite
Planeja >
Análise Teste de Sistema
Planeja >
Desenho Teste de Integração
Planeja >
Código Teste de Unidade
@CharlesFortes

19. Introdução ao
Test-Driven Development
.com
O problema deste modelo é que o teste muitas vezes se torna viciado,
acaba sendo um teste criado para provar que o código funciona, e não
para validar se há ou não falhas
@CharlesFortes

20. Introdução ao
Test-Driven Development
.com
Pensando em como solucionar este problema, foi criado o TDD
Desenho reaproveitado de uma tirinha do site vidadeprogramador.com.br
O texto apresentado não é o texto original da tirinha.
@CharlesFortes

21. Introdução ao
Test-Driven Development
.com
Pensando em como solucionar este problema, foi criado o TDD
Planeja >
Requisitos Teste de Aceite
Análise Planeja > Teste de Sistema
Desenho Planeja > Teste de Integração
Planeja >
Teste de Unidade Código
@CharlesFortes

22. Introdução ao
Test-Driven Development
.com
Quem diz: _“o importante é testar, não importa
quando” esta errado, porque entende TDD como
uma abordagem de testes.
TDD utiliza testes para dirigir o desenvolvimento
da aplicação
@CharlesFortes

23. Introdução ao
Test-Driven Development
.com
“Testes escritos antes do código da aplicação,
antes de serem testes, são especificações”
Giovanni Bassi
@CharlesFortes

24. Introdução ao
Test-Driven Development
.com
Dentre as vantagens desta abordagem estão o fato de que se desenvolve
apenas o necessário e com agilidade
E a segurança de que a aplicação continuará funcionando no
futuro (evitando regressões), qualquer erro que apareça pode ser facilmente
encontrado sem ficar debugando o código a esmo.
@CharlesFortes

25. Introdução ao
Test-Driven Development
.com
O TDD NÃO realiza todos os testes que o projeto precisa, ele apenas fornece
uma direção para ser seguida durante o desenvolvimento que foca as
especificações. Ele testa se o que foi solicitado funciona.
O TDD deve ser realizado pelo desenvolvedor, de forma que guie
seu raciocínio quanto a como e o que implementar
@CharlesFortes

26. Introdução ao
Test-Driven Development
.com
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
Lets Test
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
@CharlesFortes

27. Introdução ao
Test-Driven Development
.com
Pensando em como solucionar este problema, foi criado o TDD
@CharlesFortes

28. Introdução ao
Test-Driven Development Pré-Condição .com
Deve ser preparado o ambiente de testes, suas pré-condições
Podem ser usados MOCKs, fakes, querys, a execução de
outro teste (ou outros), etc...
@CharlesFortes

29. Introdução ao
Test-Driven Development Pré-Condição .com
O Visual Studio usa a marcação TestInitialize em um método para
executar algo que prepara o ambiente.
@CharlesFortes

30. Introdução ao
Domain-Driven Design
.com
u Escreva o Código para que ele passe Rode todos os testes Refatore Escreva o Teste Verifiq
@CharlesFortes

31. Introdução ao
Domain-Driven Design
.com
@CharlesFortes

32. Introdução ao
Domain-Driven Design
.com
e Verifique se ele falhou Escreva o Código para que ele passe Rode todos os testes Refatore E
@CharlesFortes

33. Introdução ao
Domain-Driven Design
.com
@CharlesFortes

34. Introdução ao
Domain-Driven Design
.com
que se ele falhou Escreva o Código para que ele passe Rode todos os testes Refatore Escreva
@CharlesFortes

35. Introdução ao
Domain-Driven Design
.com
@CharlesFortes

36. Introdução ao
Domain-Driven Design
.com
que se ele falhou Escreva o Código para que ele passe Rode todos os testes Refatore Escreva
@CharlesFortes

37. Introdução ao
Domain-Driven Design
.com
@CharlesFortes

38. Introdução ao
Domain-Driven Design
.com
que se ele falhou Escreva o Código para que ele passe Rode todos os testes Refatore Es
@CharlesFortes

39. Introdução ao
Test-Driven Development
.com
VB6
@CharlesFortes

40. Introdução ao
Test-Driven Development
.com
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
Lets Code
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
01000001111010101011111100000111001101101010010101010
00001110011011010100101010100100000111101000000011100
@CharlesFortes

41. Introdução ao
Test-Driven Development
.com
http://bugbang.com.br
http://artofunittesting.com
http://www.agiledata.org/essays/tdd.html
@CharlesFortes

42. Introdução ao
Test-Driven Development
@CharlesFortes
br.linkedin.com/in/charlesfortes
pangeanet.org/profile/charlesfortes