Esta apresentação explana sobre o que é o TDD, suas vantagens e como utiliza-lo em um ambiente Agil.

1. Gustavo Fontes
Desenvolvedor de software
Email: Gustavo.ferrazfontes@gmail.com
Blog: http://praisethecode.wordpress.com

2. O que é ?
TDD é uma metodologia de desenvolvimento onde define
que: todo o código a ser escrito parte de um teste, ou seja,
você primeiro escreve o teste da forma mais simples que
puder antes mesmo dos recursos necessários existirem.
Obviamente o teste irá falhar, então somente após esta falha
você inicia a implementação dos recursos

3. O que é ?

4. Por que adotar?
1) TDD Garante a qualidade do código desde o inicio
2) A maioria dos praticantes de TDD seguem os princípios SOLID
3) TDD garante um alto nível de fidelidade entre o código e os requisitos de
negocio
4) TDD estimula a criação do simples, focando mais em libraries e API’s
5) TDD estimula a comunicação com o negocio. Criando os testes, você
estimula a interação com os usuários de negocio
6) TDD ajuda a manter os códigos não utilizados fora do sistema, ajudando
assim, no entendimento e na preservação do sistema

5. Beneficio
Fonte:
http://powersoftwo.agileinstitute.com/2012/08/the-roi-of-test-driven-development.html
http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf
http://www.somkiat.cc/tdd-wrong-invest/

6. Ciclo de vida do projeto
1. Escrever o teste antes de escrever o código
• Garante que você nunca escreva um código que não adicione
valor para à aplicação
2. Escrever somente o necessário (Just Enough) para o
teste passar
3. Analisar as áreas com maior potencial de melhoria à ser
aplicada

7. 1. Escrever o teste primeiro
Ao escrever primeiro o teste, o resultado será uma falha. Isso
porque o seu teste está tentando instanciar objetos e executar
métodos que ainda não existe.
Para quem está iniciando, esta primeira etapa pode parecer
desnecessária, mas ela garante que você não escreva código
sem valor para aplicação, e que a funcionalidade a ser testada
ainda não exista. Por isso, a importância de que você inicie pelo
teste.

8. 2. Escrever somente o necessário
Uma vez que você cria um teste, o objetivo é escrever somente
o necessário para fazer o teste passar. Nem mais, nem menos.
A estratégia a ser tomada é como ir do ponto “A” (um teste que
falhou) para o ponto “B” (um teste que passou) pelo caminho
mais curto e rápido possível.
Nesta etapa, você não precisa se preocupar com outros
aspectos, como por exemplo, se o código esta seguindo boas
praticas, se suas variáveis estão com uma nomenclatura
intuitiva, se é um código elegante. O objetivo é fazer o teste
passar.

9. 3. Refatoração
Esta é a etapa onde você irá melhorar o nome daquela variável,
corrigir duplicações de código, verificar se o seu código não
esta violando nenhum principio SOLID e se é possível aplicar
algum pattern para melhorar o código.
O objetivo nesta etapa é deixar o seu código o mais coeso e
sucinto possível.
Após realizar todas essas verificações, é hora de executar
novamente o teste para garantir que a refatoração realizada não
“quebrou” nenhum teste.

11. Boas Praticas

12. SOLID PRINCIPLES
Os princípios S.O.L.I.D. foram introduzidos na comunidade pelo
Robert “Uncle Bob” Martin.
São 5 princípios para desenvolvimento de software que utiliza
OOP com o objetivo levar os softwares para um alto nível de
qualidade.

13. SOLID PRINCIPLES
OS 5 princípios são divididos em:
• Single Responsibility Principle
• Open/close principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

14. SOLID PRINCIPLES
• Single responsibility principle (SRP)ou principio da
responsabilidade única, define que, cada método ou classe
deve ter somente uma razão para ser alterado.
• Open/Close principle(OCP) ou principio do aberto/fechado,
defini que, métodos e classes devem estar abertos para
extensão e fechados para modificação.
• Liskov principle(LSP) ou principio de liskov, define que, i,
objeto utilizado em uma aplicação pode ser substituído pela
super classe sem afetar o funcionamento da mesma.

15. SOLID PRINCIPLES
• Interface segregation principle(ISP) ou principio da segregação
de interface, define que, a classe cliente não deve ser forçada
implementar métodos de uma interface que não são utilizados.
• Dependency Inversion Principle ou principio da inversão de
dependência, define que, os códigos devem depender de
abstrações(interfaces/classes abstratas) e não de
implementações concretas

16. MOCK

17. Mock
• Definição
• Mock é um termo genérico utilizado para referenciar
uma família de objetos substitutos, que permitem isolar
as classes de um sistema de forma bastante simples.
• Existem três tipos de Mock
• Dummy, Fake, stub e Mock

18. Dummy
• Dummy é um tipo de mock que substitui um recurso
externo. Ele retorna um resposta predefinida para um
método quando o mesmo é invocado.
• Não pode variar o retorno baseando-se no parâmetro de
entrada.

19. Dummy

20. Dummy

21. Fakes and stub
• Fakes e stub podem variar seu retorno baseando-se no
parâmetro de retorno

22. Fakes and stub

23. Fakes and stub

24. Mock
• Oferece as mesmas funcionalidades de um stub e/ou Fakes
• Podem ter regras definidas para determinar em que ordem
métodos foram chamados
• Podem acompanhar quantas vezes o método foi chamado

25. Mock

26. Mock

27. Moq Framework
• Facilidade e agilidade na criação de Mocks
• Fortemente tipado
• Alta granularidade
• Intuitivo

28. Moq Framework

29. Moq Framework

30. Resumo
• Mock são uteis quando você precisa substituir interações
mais complexas
• Fakes, stubs são uteis para testes mais simples. Tente
sempre dar preferencia para eles

31. Utilizando TDD no inicio de um projeto

32. Definindo o projeto
Uma aplicação é definida por um conjunto de requisitos
funcionais e não funcionais.
Os requisitos não funcionais descrevem um conjunto de
condições ou parâmetros dentro do qual são necessários para a
aplicação existir.
Requisitos funcionais descrevem o que a aplicação deve fazer
para atender o negócio.
Depois que estas informações são coletadas, os requisitos
funcionais são utilizados para criar as “user stories” (histórias
do usuário). Estas “User stories” são decompostas em features
que são atribuídas para os desenvolvedores para ser construída.

33. Project Overview
É uma descrição de alto nível das necessidades de negócio
da aplicação. Ela descreve o objetivo geral da aplicação, os
work flow chaves, e as principais funções do usuário
O objetivo da visão geral de um projeto é identificar as
necessidades tendo uma visão objetiva e um pouco isolada
da tecnologia que será usada. A tecnologia deve atender as
necessidades do negócio, não o contrário.

34. Definindo as User Stories
No desenvolvimento ágil, as user stories define as regras de
negócio e o work flow da aplicação. As user stories, que são
definidas pela necessidade do negócio, são os requisitos
funcionais da aplicação.
1. As user stories são coletadas e decompostas em
features
2. As features serão atribuídas para um desenvolvedor para
definir os seus testes
3. por fim, o desenvolvimento desses testes irá guiar e
definir como será o design da aplicação

35. Coletando as User stories
Entrevistas com o cliente podem ser uteis, pois permite que
o desenvolvedor tenha uma comunicação mais “intima” com
o usuário, possibilitando assim, um melhor resultado neste
processo de coleta. As entrevistas podem ser guiadas por
questões formais e seguidas de uma sessão de respostas
da mesma, uma conversa informal na qual buscamos extrair
os requisitos de negócio necessários para a aplicação.

36. Coletando as User stories
Tecnicas utilizadas:
1. Shadowing: significa simplesmente acompanhar os usuários por
um período e observar como eles executam o seu trabalho. A
técnica Shadowing, permite a nos, aprender bastante sobre os
problemas que acontecem no dia à dia do usuário.
2. JAD sessions: O conceito desta técnica é reunir de uma só vez
todos os usuários e coletar as users stories de cada usuário. O
benefício de JAD sessions é que todas as divergências de regra de
negócio que são comuns de acontecer, são discutidas entre os
próprios usuários e resolvidas imediatamente. Este processo pode
ser útil para os usuários que entendem as necessidades de outras
partes do negócio, e como essas necessidades estão relacionadas
com as outras.

37. Referencias
•