unit tests (com e sem tdd), bdd, métricas
DESCRIPTION
Minha apresentação no ALM Summit 2012TRANSCRIPT
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!?
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
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 [[email protected]]
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 [[email protected]]
Conceituando Agilidade
agilemanifesto.org/iso/ptbr/
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
Conceituando Boas práticas
bit.ly/boas-praticas
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
Conceituando Boas práticas
bit.ly/boas-praticas
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
Conceituando Boas práticas
bit.ly/boas-praticas
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
Para pensar Desenvolver software é um processo de aprendizagem
bit.ly/dev-aprendizado
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
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 [[email protected]]
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 [[email protected]]
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 [[email protected]]
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 [[email protected]]
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 [[email protected]]
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 [[email protected]]
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 [[email protected]]
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 [[email protected]]
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 [[email protected]]
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 [[email protected]]
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 [[email protected]]
Para pensar Anatomia de um teste
SEM LINK
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
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 [[email protected]]
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 [[email protected]]
Consequência Seu teste passa a influenciar o seu Design - TDD
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
Documentação viva: Learning Tests
bit.ly/LearningTests
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
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 [[email protected]]
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 [[email protected]]
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 [[email protected]]
Antecipando a “dor”: Quanto mais cedo testarmos...
elemarjr.net/tag/BDD/
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
Walking Skeleton Sempre entregando o valor
elemarjr.net/tag/BDD/
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
Walking Skeleton Ganhamos uma fonte adicional de feedback
elemarjr.net/tag/BDD/
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
Gherkin Requisitos como cenários de uso
elemarjr.net/tag/BDD/
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
Gherkin Requisitos como cenários de uso
elemarjr.net/tag/BDD/
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
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 [[email protected]]
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 [[email protected]]
Métodos Estáticos Usando Microsoft Fakes
Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [[email protected]]
Por hoje, era isso!
FIM: Já devo ter estourado o tempo