Intrudução ao Behavior Driven Development (BDD) com Ruby on Rails
Convergido: TDD + ATDD + BDD + xUnit Patterns + Dependency Injection
-
Upload
marco-baccaro -
Category
Technology
-
view
412 -
download
2
description
Transcript of Convergido: TDD + ATDD + BDD + xUnit Patterns + Dependency Injection
Tom ShinderPrincipal WriterMicrosoft SCD iX Solutions Group
Yuri DiogenesSenior Technical WriterMicrosoft SCD iX Foundations Group
Josh AdamsSenior Program ManagerMicrosoft Enterprise Engineer Center (EEC)
Giespp
Desenvolvimento ágil enriquecido com práticas de testabilidade
Marco BaccaroArquiteto de SistemasUnidade de tecnologia Giespp
AgendaRestrospectiva
Como desenvolvemos software atualmente?Comprometimento
ConceitoTest-Driven DevelopmentAcceptance Test Driven DevelopmentBehavior-Driven Development
PadrõesMocks, Stubs, Dummy e FakeFrameworksDependency Injection
Retrospectiva
Como construímos softwares atualmente?
Núcleo de Capacitação Permanente
Como construímos software atualmente
Codificamos
Erramos
Depuramos
Desenvolvemos e nunca mais testamos.Não temos segurança no produto interno.Ausência de um fluxo inteligente mediante os requisitos de negócio.
Como construímos software atualmente
Todo código é culpado até que se prove ser inocente.
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.
Como construímos software atualmente
Como construímos software atualmente
Usuário final
Controle de qualidade
Desenvolvimento
Implantação
Comprometimento
Devemos projetar organicamente com código, executando e fornecendo feedback entre as decisões.
Devemos escrever nossos próprio testes, não podemos esperar que outra pessoa teste nossa implementação.
Nosso ambiente de desenvolvimento deve fornecer respostas rápidas a pequenas mudanças.
Nosso projeto deve consistir em muitos componentes altamente coesos e fracamente acoplados para tornar os testes mais fáceis.
Test-Driven DevelopmentUm, dois, três, testando…
Núcleo de Capacitação Permanente
Conceito
Desenvolvimento guiado por teste ajuda times ágeis a mudar rapidamente assegurando alta qualidade.
Benefícios
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.
Conceito
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
Refatorar
SucessoErro
Resultados
Quanto mais cedo encontrar e corrigir defeitos, mais barato é!
Melhorar o relacionamento no time, você não é culpado por quebrar builds.
Melhorar a satisfação do cliente.
Flexibilidade em mudanças tecnológicas.
Coragem!
Não utilizar porque…
Não sei como testarVai demorar muito mais.
Isso não dá para testar
A funcionalidade é muito fácil.
Melhor deixar testes com os testadores
Você não tem tempo para criar teste unitário porque gasta tempo demais depurando.
Importante
1. Os testes devem evoluir, bem como o código evolui;
2. Teste não atualizado é apenas código legado;3. Escrever teste é um processo gradativo
Acceptance Test Driven DevelopmentEquipe colaborando com critérios de aceitação.
Núcleo de Capacitação Permanente
Acceptance Test Driven Development
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.
Acceptance Test Driven Development• 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_mettest_valid_returns_false_when_password_less_than_6_charstest_valid_returns_false_when_password_missing_symboltest_valid_returns_false_when_password_missing_lettertest_valid_returns_false_when_password_missing_number
Behavior-driven developmentEncoranjando e guiando a prática de TDD no processo.
Núcleo de Capacitação Permanente
Behavior-Driven Development
Encoraja a colaboração entre as várias partes envolvidas em um projeto de software: desenvolvedores, QA e analistas não técnicos ou de negócio.
Como um formato de documentação, a técnica tem a vantagem de promover a criação de documentos vivos, que podem ser executados contra o que está sendo implementado.
BDD é a linguagem e interações usadas no processo de desenvolvimento, que utiliza a língua nativa combinando com a linguagem ubíqua existente no processo de desenvolvimento de software.
Behavior-Driven Development
Qual o nome do meu teste?O que devo testar primeiro?
Quando devo testar?Esse teste faz sentido?
Dúvidas existem na hora de construir testes...
Behavior-Driven Development
Cenário 1: Itens devolvidos devem retornar para o estoqueDado que um cliente compra um jumper pretoE eu tenho três jumper pretos no estoqueQuando ele retorna com o jumper preto para reembolsoEntão eu devo ter quatro jumpers pretos no estoque
Cenário 2: Itens substituídos devem ser retornados ao estoqueDado que uma cliente compra um vestido azulE eu tenho dois vestidos azuis no estoqueE eu tenho três vestidos pretos no estoqueQuando ela retorna com o vestido para uma troca por um pretoEntão eu devo ter três vestidos azuis no estoqueE dois vestidos pretos no estoque
Behavior-Driven Development
Padrões
xUnit Patterns. Aplicar o que já se sabe ajuda!
Núcleo de Capacitação Permanente
Passos para escrever unit test
Exercises
Setup
Verify
Teardown
Fake
Fake são objetos extremamente leves e performáticos, construídos para simular uma funcionalidade de um componente que o sut depende, ao invés do doc real.
Devemos utilizar objetos Fakes sempre que sut 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.
Fake
Fake Web Services
Fake Database
Fake Service Layer
Dummy
Utilizamos Dummy object sempre que nós precisamos utilizar objetos como atributo de outro objeto, fornecer argumentos fictícios em métodos do sut ou fixture object complementar. Dummy não é usado diretamente pelo sut, assim seu
comportamento é irrelevante como um null object pattern é usado pelo sut, pois é projetado para fazer nada.
Dummy
Dummy
Mock
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 sut em Test Double.
Mock
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.
Mock
Mock
Mock
Stub
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'.
Stub
Stub
Stub
StubMesmo teste de Stub para Mock.
Mock vs Stub
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.
Parecido não é igual
Detalhes importam!
Resumo xUnit PatternsPadrão Propósito Tem
ComportamentoInjeta 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ãoNão, nunca chamado
Não, nunca chamado
NãoNull, "Ignored String", new Object()
Test Stub Verify indirect inputs of SUT
Sim Sim Ignorá-los Inputs
Test SpyVerify indirect outputs of SUT
Sim OpicionalCaptura-los para verificação posterior
Inputs (opicional)
Mock Object Verifique saídas indiretas do SUT
Sim optionalverifica a exatidão de encontro às expectativas
Inputs e outputs (opcional)
Fake Object
Executar (unrunnable) testes (mais rápido)
Sim Não Usa-los NenhumEmulador de banco de dados em memória
Temporary Test Stub
Stand in for procedural code not yet written
Sim Nao Usa-los NenhumEmulador de banco de dados em memória
Dependency Injection
Padrão de projeto com um princípio de separação de comportamento na resolução de dependências.
Em outras palavras: uma técnica para a desacoplamento de software com componentes altamente dependentes.
Dependency Injection
Princípio abstrato de IoC:
Não nos chame, deixe que nós chamaremos você!
Dependency Injection
Invertion of Control (IoC)
Service Locator Events Delegates
Template Methods Pattern
Dependency Injection
Construtor Injection
Property Injection
Method Injection
Dependency Injection
Vantagens:
• Existe uma separação entre a execução de uma determinada tarefa de aplicação.
• Cada sistema se concentra para o que foi projetado.
• Os sistemas não fazer suposições sobre o que outros sistemas fazem ou deveriam fazer.
• Substituição de sistemas não terá efeitos colaterais em outros sistemas.
Dependency Injection
Castle Windsor
Structure Map
Spring.Net Unity
Ninject AutoFac
Referências
Obrigado
Giespp