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

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

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!?

http://facebook.com/elemarjr

http://elemarjr.net/


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




http://www.infoq.com/br/author/Elemar-Jr

http://fluentil.org/

http://github.com/elemarjr


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




Conceituando Agilidade

agilemanifesto.org/iso/ptbr/



http://agilemanifesto.org/iso/ptbr/




Conceituando Boas práticas

bit.ly/boas-praticas



http://bit.ly/boas-praticas














Para pensar Desenvolver software é um processo de aprendizagem

bit.ly/dev-aprendizado



http://bit.ly/dev-aprendizado


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)






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)







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?




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)



http://bit.ly/tdd-escolha-pessoal


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)



http://bit.ly/leandro-code-metrics

http://elemarjr.net/tag/dojo/

http://bit.ly/dev-msbuild


Unit Tests and TDD in a Nutshell

Automatizando o óbvio: Teste!

elemarjr.net/tag/testes/



http://elemarjr.net/tag/testes/


Importante Você deveria testar o seu software

bit.ly/dev-falacia

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



http://bit.ly/dev-falacia




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)





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)



http://en.wikipedia.org/wiki/Unit_testing


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



http://bit.ly/Iixhkv


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?!)



http://bit.ly/Iixhkv


Para pensar Anatomia de um teste

SEM LINK




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

SEM LINK




Para pensar Indicadores de Qualidade

Complexidade Ciclomática,

Índice de Manutenabilidade,

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

Code Coverage,

Code Clones




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




Documentação viva: Learning Tests

bit.ly/LearningTests



http://bit.ly/LearningTests




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/




















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







Walking Skeleton Sempre entregando o valor







Walking Skeleton Ganhamos uma fonte adicional de feedback







Gherkin Requisitos como cenários de uso







Gherkin Requisitos como cenários de uso







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




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

bit.ly/teste_metodos_privados



http://bit.ly/teste_metodos_privados




Métodos Estáticos Usando Microsoft Fakes




Por hoje, era isso!

FIM: Já devo ter estourado o tempo



Technology

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