Your SlideShare is downloading. ×
Convergido: TDD + ATDD + BDD + xUnit Patterns + Dependency Injection
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Convergido: TDD + ATDD + BDD + xUnit Patterns + Dependency Injection

364
views

Published on

Workshop sobre desenvolvimento ágil enriquecido com práticas de testabilidade e design flexível. …

Workshop sobre desenvolvimento ágil enriquecido com práticas de testabilidade e design flexível.

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
364
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • No cronograma, o testesempre é oprimeiro a ser cortadoparaentregar no prazo.Depois de adicionar 200 classes, é muitomaisdifícilmudar.Nãoestamosfalandoapenas de teste, mas de prática de design. Fazerestruturacoesa, objetiva, flexível!Simplicidade, vamosparar de imaginar e colocar o mínimonecessário.TDD nosfazpensarem boa práticas de arquitetura, nosfazdesenvolverpara interfaces.http://blog.lambda3.com.br/2009/10/tdd-nao-existe/http://viniciusquaiato.com/blog/tdd-test-driven-development-c-parte-ii/http://viniciusquaiato.com/blog/tdd-test-driven-development-c-parte-iii/
  • Teste de unidadetesta o pedaço, nãoquerdizerquesomandotodas as unidadeseutenho um sistema. Precisamospensaremsistema, pensarem user story. Vamosenriquecernãopensandoemteste de classes e tecnologias e vamostrazer o negócio, a linguagem do clientenos testes.
  • depended-on component (DOC)An individual class or a large-grained component on which the system under test (SUT) depends. The dependency is usually one of delegation via method calls. In test automation, it is primarily of interest in that we need to be able to examine and control its interactions with the SUT to get complete test coverage.SUTThe "system under test". It is short for "whatever thing we are testing" and is always defined from the perspective of the test. When we are writing unit tests the system under test (SUT) is whatever class (a.k.a. CUT), object (a.k.a. OUT) or method(s) (a.k.a. MUT) we are testing; when we are writing customer tests, the SUT is probably the entire application (a.k.a. AUT) or at least a major subsystem of it. The parts of the application that we are notverifying in this particular test may still be involved as a depended-on component (DOC).
  • http://xunitpatterns.com/Fake%20Object.htmlhttp://xunitpatterns.com/DOC.html
  • http://xunitpatterns.com/Fake%20Object.htmlhttp://xunitpatterns.com/DOC.html
  • http://xunitpatterns.com/Dummy%20Object.html
  • http://xunitpatterns.com/Dummy%20Object.html
  • http://www.agile-code.com/blog/mocking-with-moq/http://xunitpatterns.com/Mock%20Object.html
  • http://www.agile-code.com/blog/mocking-with-moq/http://xunitpatterns.com/Mock%20Object.html
  • http://www.agile-code.com/blog/mocking-with-moq/http://xunitpatterns.com/Mock%20Object.html
  • http://www.agile-code.com/blog/mocking-with-moq/http://xunitpatterns.com/Mock%20Object.html
  • http://www.agile-code.com/blog/mocking-with-moq/http://xunitpatterns.com/Mock%20Object.html
  • http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html
  • Dependency Injection is a set of software design principles and patterns that enable us to develop loosely coupled code.
  • Inversion of control (IoC) is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming.
  • Inversion of control (IoC) is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming.
  • Inversion of control (IoC) is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming.
  • Inversion of control (IoC) is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming.
  • Transcript

    • 1. Codificamos Erramos Depuramos
    • 2.  Não existe refactoring, apenas rework.  Se tiver funcionando, não rela a mão.  Teste é para os fracos.  Quanto mais XGH você faz, mais precisará fazer.  Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.  Seja autêntico, XGH não respeita padrões. Escreva o código como você bem entender, se resolver o problema, commit e era isso.
    • 3. Usuáriofinal Controlede qualidade Desenvolvimento Implantação
    • 4. Assegurar qualidade. Manter código limpo, simples e testável. Prover documentação para membros técnicos. Repetir testes - Regressão Preparados para mudar rapidamente.
    • 5. Adicionar um teste rapidamente Rodar todos os testes e ver o mais nova falhando Fazer uma pequena mudança Rodar todos os testes e ver todos funcionando Refatorar para remover duplicações SucessoErro
    • 6. Não sei como testar Vai demorar muito mais. Isso não dá para testar A funcionalidade é muito fácil. Melhor deixar testes com os testadores
    • 7. ATDD é o ato de se definir testes de aceitação colaborativa no reflexão de requisitos de negócio, resultando numa melhor compreensão dos objetivos de uma estória. Os testes em ATDD nos forçam a chegar a um ponto de acordo concreto sobre o exato comportamento que se espera que o software deva ter.
    • 8. • Criar uma conta com uma senha • Efetuar o login com um nome de usuário válido e senha • O que deve acontecer se um usuário informar uma senha insegura? • Você pode nos dar exemplos de senhas que você considera seguras e inseguras? • Quais são exatamente os símbolos? • E quanto a espaços? • E o que fazer com relação a palavras de dicionário com substituições óbvias que atendam • aos critérios mais ainda possam ser inseguras, como 'p@ssw0rd'?” • E quanto a contas já existentes? • Quando você vai considerar que esta funcionalidade está 'funcionando'? • O que deve acontecer se um usuário informar uma senha insegura? • Você pode nos dar exemplos de senhas que você considera seguras e inseguras? • Quais são exatamente os símbolos? • E quanto a espaços? • E o que fazer com relação a palavras de dicionário com substituições óbvias que atendam • aos critérios mais ainda possam ser inseguras, como 'p@ssw0rd'?” • E quanto a contas já existentes? • Quando você vai considerar que esta funcionalidade está 'funcionando'? test_valid_returns_true_when_all_conventions_met test_valid_returns_false_when_password_less_than_6_chars test_valid_returns_false_when_password_missing_symbol test_valid_returns_false_when_password_missing_letter test_valid_returns_false_when_password_missing_number
    • 9. Itens devolvidos devem retornar para o estoque que um cliente compra um jumper preto eu tenho três jumper pretos no estoque ele retorna com o jumper preto para reembolso eu devo ter quatro jumpers pretos no estoque Itens substituídos devem ser retornados ao estoque que uma cliente compra um vestido azul eu tenho dois vestidos azuis no estoque eu tenho três vestidos pretos no estoque ela retorna com o vestido para uma troca por um preto eu devo ter três vestidos azuis no estoque dois vestidos pretos no estoque
    • 10. Fake são objetos extremamente leves e performáticos, construídos para simular uma funcionalidade de um componente que o depende, ao invés do real. Devemos utilizar objetos Fakes sempre que depende de outros componentes: 1. Que não estão disponíveis; 2. São difíceis de serem testadas (por exemplo post em páginas web); 3. Resultam em maior lentidão na execução dos testes; 4. Maior complexidade no comportamento do método que vale a pena um Test Stub ou Mock object.
    • 11. Objetos Mock são criados para testar o comportamento de algum outro objeto (real). Portanto, mocking é fingir completamente o objeto real e fazer algumas operações de uma forma controlada para que o (teste) resultado como válido. Mock é uma maneira poderosa de implementar verificação de comportamento evitando a duplicação de código de teste entre os testes semelhantes, delegando a tarefa de verificar as saídas do em Test Double.
    • 12. Devemos utilizar objetos Mocks quando: 1. O objeto fornece resultados não-determinísticos (por exemplo, o tempo atual ou a temperatura atual); 2. Possuem estados que não são fáceis de criar ou reproduzir (por exemplo, um erro de rede); 3. É lento (por exemplo, uma base de dados completa, que tem de ser inicializado antes do ensaio); 4. Ainda não existe ou pode mudar o comportamento; 5. Necessidade de incluir informações e métodos exclusivos para fins de teste e não para a sua tarefa real.
    • 13. Providenciam respostas pré-configuradas para as chamadas feitas durante os testes, normalmente não respondem a nada que não esteja programado para o teste. Stubs também podem gravar informações sobre as chamadas, como um gateway que lembra as mensagens que 'enviou', ou talvez apenas quantas mensagens 'enviou'.
    • 14. Mesmo teste de Stub para Mock.
    • 15. Stubs providenciam respostas pré- configuradas para as chamadas feitas durante os testes, normalmente não respondem a nada que não esteja programado para o teste. Também podem gravar informações sobre as chamadas, estado das informações. Mocks são objetos pré-programados com informações que formam uma especificação das chamadas que esperam receber.
    • 16. Padrão Propósito Tem Comportamento Injeta entrada indiretas no SUT Manipula saídas indiretas do SUT Valores fornecidos pelo testador Exemplos Dummy Object Atributo ou parâmetro do método Não Não, nunca chamado Não, nunca chamado Não Null, "Ignored String", new Object() Test Stub Verify indirect inputs of SUT Sim Sim Ignorá-los Inputs Test Spy Verify indirect outputs of SUT Sim Opicional Captura-los para verificação posterior Inputs (opicional) Mock Object Verifique saídas indiretas do SUT Sim optional verifica a exatidão de encontro às expectativas Inputs e outputs (opcional) Fake Object Executar (unrunnable) testes (mais rápido) Sim Não Usa-los Nenhum Emulador de banco de dados em memória Temporary Test Stub Stand in for procedural code not yet written Sim Nao Usa-los Nenhum Emulador de banco de dados em memória
    • 17. Invertion of Control (IoC) Service Locator Events Delegates Template Methods Pattern Dependency Injection Construtor Injection Property Injection Method Injection