Unit Tests (com e sem TDD), BDD, Métricas

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Considerações sobre Unit Tests (com e sem TDD), BDD, Fakes, Code Clone (e algumas métricas)

Elemar JRMicrosoft C# MVPGerente de P&D – Promob Solutions

O que temos para hoje: Por que estamos aqui!?

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Apresentando Elemar JR

P&D na Promob onde trabalha há 14 anos

Microsoft C# MVPjaneiro 2012

Integrante do Void Podcastcom Leandro Daniel [@leandronet] e Vinícius Quaiato [@vquaiato]

Blogueiro e articulistaelemarjr.net e www.infoq.com/br/author/Elemar-Jr.

FOSS developerfluentil.org e github.com/elemarjr

32 anos, pai, DEV e nerdArquiteto, enxadrista, (ex) apaixonado por vinhos. Gosta de filosofia e teologia

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Definindo os “porquês”

Afinal, por que precisamos pensar sobre Unit Tests, BDD, Fakes, Code Clone e Whatever!?

Antes de começar: Precisamos entender os motivos

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Conceituando Agilidade

agilemanifesto.org/iso/ptbr/

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Conceituando Boas práticas

bit.ly/boas-praticas

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Conceituando Boas práticas

bit.ly/boas-praticas

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Conceituando Boas práticas

bit.ly/boas-praticas

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Para pensar Desenvolver software é um processo de aprendizagem

bit.ly/dev-aprendizado

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Para pensar Em um projeto de software, SEMPRE, há surpresas

In spite of the best efforts of our discipline, all but the most routine projects have elements of surprise. Interesting projects – those likely to provide the most benefit – usually have a lot of surprises. (Growing Object-Oriented Software, Guided by Tests)

bit.ly/dev-aprendizado

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Para pensar Em um projeto de software, SEMPRE, há mudanças

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr]

They all know there will be changes, they just don’t know what changes. They need a process that will help them cope with uncertainty as their experience grows – to anticipate unanticipated chances.(Growing Object-Oriented Software, Guided by Tests)

bit.ly/dev-aprendizado

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Para pensar Feedback é importante

bit.ly/dev-feedback

Feedback de seu códigoOs melhores códigos são os mais fáceis de ler.

Feedback de seus colegasEles sabem se seu código funciona e se é fácil de ler.

Feedback de seus clientesInternos e externos, sem esquecer dos especialistas de domínio.

Feedback de seus testesSe não está fácil de testar, não está fácil de manter.

Feedback de seu buildQuanto esforço para colocar uma alteração em produção?

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Para pensar Boas práticas são indicativos de senioridade

bit.ly/tdd-escolha-pessoal

A preguiça é a mãe do progresso. Se o homem não tivesse preguiça de caminhar, não teria inventado a roda.(Mário Quintana)

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Para agir Feedback é importante

bit.ly/dev-feedback

Feedback de seu códigoUse métricas! (bit.ly/leandro-code-metrics)

Feedback de seus colegasUse Daily-meetings e participe de Coding Dojos (elemarjr.net/tag/dojo/)

Feedback de seus clientes“Automatize” suas especificações

Feedback de seus testesAutomatize seus testes “de unidade e de aceitação”.

Feedback de seu buildAutomatize seu Build e seu Deploy. (http://bit.ly/dev-msbuild)

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Unit Tests and TDD in a Nutshell

Automatizando o óbvio: Teste!

elemarjr.net/tag/testes/

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Importante Você deveria testar o seu software

bit.ly/dev-falacia

Independente de pressão de cronograma, você deveria testar o seu software

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Para pensar O que você tem a perder?

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr]

... you have nothing to lose but your bugs.(Growing Object-Oriented Software, Guided by Tests)

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Conceituando Unit Testing

en.wikipedia.org/wiki/Unit_testing

Unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use.(Wikipedia)

Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming a unit could be an entire module but is more commonly an individual function or procedure. In object-oriented programming a unit is often an entire interface, such as a class, but could be an individual method. (Wikipedia)

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Como saber O que testar?

bit.ly/Iixhkv

Right – No contexto certo, os resultados são os esperadosB – “limites” nos parâmetros/entradas (CORRECT!?)I – “prova-real” (exemplo)C – cross-check (comparação com implementações que funcionam)E – situações de falha (error conditions)P – Performance

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Como saber O que testar (parâmetros)?

bit.ly/Iixhkv

C – (Conformance) adequação a um formato;O – (Ordering) respeito a um determinado critério de ordenação;R – (Range) intervalo válido (tipo, idade mínima e máxima);R – (Reference) acesso do SUT a outros objetosE – (Existence) valor não-nulo, tão pouco não-vazio;C – (Cardinality) os dados fornecidos são suficientes;T – (Time) Tudo está ocorrendo na sequência certa? Em ordem e no tempo esperado?! (está sendo disparado um evento PropertyChanged quando uma propriedade é alterada?!)

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Para pensar Anatomia de um teste

SEM LINK

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Automatização A forma mais fácil de obter feedback contínuo

SEM LINK

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Para pensar Indicadores de Qualidade

Complexidade Ciclomática,

Índice de Manutenabilidade,

Acoplamento aferente (referenciado em), Acoplamento eferente (referência para),

Code Coverage,

Code Clones

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Consequência Seu teste passa a influenciar o seu Design - TDD

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Documentação viva: Learning Tests

bit.ly/LearningTests

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

BDD in a NutshellPorque fazer certo a coisa não implica, necessariamente, em fazer a coisa certa.

Quando a unidade é pouco: Testes de Integração e de Aceitação

elemarjr.net/tag/BDD/

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Quando a unidade é pouco: Testes de Integração e de Aceitação

elemarjr.net/tag/BDD/

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Quando a unidade é pouco: Testes de Integração e de Aceitação

elemarjr.net/tag/BDD/

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Antecipando a “dor”: Quanto mais cedo testarmos...

elemarjr.net/tag/BDD/

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Walking Skeleton Sempre entregando o valor

elemarjr.net/tag/BDD/

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Walking Skeleton Ganhamos uma fonte adicional de feedback

elemarjr.net/tag/BDD/

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Gherkin Requisitos como cenários de uso

elemarjr.net/tag/BDD/

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Gherkin Requisitos como cenários de uso

elemarjr.net/tag/BDD/

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Alternativas para cenários BrownfieldNem sempre podemos dar “testabilidade” – Possíveis dívidas técnicas em testes

BÔNUS: Quando o design não ajuda

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Métodos privados Testando o que não deveria ser testado

bit.ly/teste_metodos_privados

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Métodos Estáticos Usando Microsoft Fakes

Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

Por hoje, era isso!

FIM: Já devo ter estourado o tempo