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