Introdução ao TDD

237 visualizações

Publicada em

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

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
237
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Introdução ao TDD

  1. 1. Gustavo Fontes Desenvolvedor de software Email: Gustavo.ferrazfontes@gmail.com Blog: http://praisethecode.wordpress.com
  2. 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. 3. O que é ?
  4. 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. 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. 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. 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. 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. 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.
  10. 10. Boas Praticas
  11. 11. 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.
  12. 12. 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
  13. 13. 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.
  14. 14. 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
  15. 15. MOCK
  16. 16. 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
  17. 17. 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.
  18. 18. Dummy
  19. 19. Dummy
  20. 20. Fakes and stub • Fakes e stub podem variar seu retorno baseando-se no parâmetro de retorno
  21. 21. Fakes and stub
  22. 22. Fakes and stub
  23. 23. 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
  24. 24. Mock
  25. 25. Mock
  26. 26. Moq Framework • Facilidade e agilidade na criação de Mocks • Fortemente tipado • Alta granularidade • Intuitivo
  27. 27. Moq Framework
  28. 28. Moq Framework
  29. 29. 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
  30. 30. Utilizando TDD no inicio de um projeto
  31. 31. 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.
  32. 32. 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.
  33. 33. 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
  34. 34. 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.
  35. 35. 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.
  36. 36. Referencias •

×