boas praticas de testes, bad smell e outros macetes

BOAS  PRÁTICAS  DE  TESTES,  BAD  SMELL  E  OUTROS  MACETES

Por Ismael Soares

POR QUE VOCÊ TESTA SEU CÓDIGO?

ME AJUDA NO DESIGN

GARANTIR REGRAS DE NEGÓCIO

ENTENDER O NEGÓCIO

AJUDA RESOLVER PROBLEMAS COMPLEXOS

ETC.

OK,  MAS  COMO  O  TESTE  TE  AJUDA  COM  ESTAS  COISAS?

FEEDBACK!

VOCÊ  OS  ESCUTA?

Mike  Cohn  (Succeeding  with  Agile)

PIRÂMIDE  DE  TESTES

UNIDADE

MAS  O  QUE  É  UMA  UNIDADE?

UMA UNIDADE DE NEGÓCIO É UM COMPORTAMENTO DO SEU CÓDIGO!

______________________________ Martin Fowler

NÃO É UMA CLASSE OU UM MÉTODO

Thought  Works

VOCÊ DEVE SE PREOCUPAR MAIS COM O QUE

DO QUE COM COMO

ESCREVENDO  TESTES  MELHORES

Referência:

https://info.thoughtworks.com/praticas-e-tendencias-em-teste-ebook.html

#  TRATE  O  CÓDIGO  DE  TESTES  COMO  DE  PRODUÇÃO

https://8thlight.com/blog/uncle-bob/2013/09/23/Test-first.html

TEST FIRST

TESTS ARE SPECS

ROTTEN TESTS

SIMPLE DESIGN

#  UTILIZE  UM  PADRÃO  DE  TESTES

OS 3 AS - ARRANGE, ACT E ASSERT

Organizar:  Configure  suas  informações  e  qualquer  outro  dado  necessário  ao  teste

Agir:  Execute  a  ação  que  vai  validar  

Verificar:  Veja  o  que  era  esperado  realmente  aconteceu

PADRÃO BDD

#  NÃO  CONVIVA  COM  TESTES  INSTÁVEIS

ERADICATING NON-DETERMINISM IN TESTS

http://martinfowler.com/articles/nonDeterminism.html

Não  passa  segurança

Precisa  de  interpretação

Vira  paisagem  com  tempo

#  UTILIZE  DUBLES  DE  TESTES

http://rkmael.com/2014/11/13/dubles_testes/

http://rkmael.com/2014/11/17/comparando-dubles-testes/

COMPARANDO DUBLES

#  CUIDADO  COM  EXCESSO  DE  MOCKS

SEM PERCEBER VOCÊ PODE ESTAR MOCKANDO UM COMPORTAMENTO

QUANDO USAR MOCKS?

Quando  o  comportamento  não  é  responsabilidade  da  unidade  testada.

Exemplo:  um  Service  chamando  outro,  um  Service  chamando  um  DAO,  um  Controller  chamando  um  Service,  etc.

E UMA REGRA CHAMADA DENTRO DE UM MODEL/ENTITY, DEVO MOCKAR?

MÁS  PRÁTICAS

#  TUDO  NO  MÉTODO  BEFORE

@Before  -­‐  uma  vez  antes  de  cada  teste

@BeforeClass  -­‐  uma  vez  apenas  antes  de  todos  os  testes

@After  -­‐  uma  vez  depois  de  cada  teste

@AfterClass  -­‐  uma  vez  apenas  depois  de  todos  os  testes

#NÃO  EVIDENCIAR  O  CENÁRIO

ERRADO

CORRETO

#CENARIOS  GIGANTES

SE O CENÁRIO ESTA MUITO GRANDE É PORQUE SEU

CÓDIGO ESTÁ MUITO ACOPLADO

#CENARIOS  IMPRONUNCIAVEIS

deveRetornarMensagemDeValidacaoDaDataDeEmissaoEBloquearANotaFiscalQuandoOUsuarioNaoTiverPermissoesEADataDeEmissaoUltrapassarADataParametrizadaEOStatusDeRecebimen

toForDiferenteDeReceberComDataAcimaDoParametrizado

SE VOCÊ NÃO CONSEGUE EXPRESSAR DE FORMA

SIMPLES UM CENARIO, É SINAL DE QUE ESTA MUITO

COMPLEXO

#TESTE  DE  EXCEPTION  SE  VALIDAR  A  MENSAGEM

ERRADO

CORRETO

#NÃO  VALIDAR  A  ORDEM  DAS  INTERAÇÕES

ERRADO

CORRETO

#ALTERAR  O  CÓDIGO  DE  PRODUÇÃO  APENAS  POR  CAUSA  DOS  TESTES

DEIXAR O MÉTODO DEFAULT PRA TESTA-LO

CRIAR SETTER PARA FAZER INJEÇÃO DE DEPENDÊNCIA

CRIAR MÉTODO PARA ALTERAR O ESTADO DO CÓDIGO DURANTE O TESTE

Obrigado@rkmael

rkmael@hotmail.com

rkmael.com