importancia dos testes automatizados

A importância dos testes automatizados

Rafael Ponte@rponte

Tuesday, October 18, 2011

@rponte


antes de começarmos...


quem aqui já programa?


quem aqui já programa?Java? .Net? Ruby? PhP? C?

Pascal?


e quem já trabalha na área?


e quem escreve testes?


eu conheço alguém que escreve...


e acho que muitos aqui também já o conhecemeu conheço alguém que escreve...


@yuriadamsO garoto prodígio dos testes.


ME MATA DE

ORGULHO!


desenvolver software é uma luta contra complexidade


toda linha de código que escrevemos pode ser um ponto de

falha


toda linha de código que escrevemos pode ser um ponto de

falha crítico


estudamos e aplicamos práticas para tentarmos diminuir estes

riscos


testarTuesday, October 18, 2011

por que testar?


para verificar se o sistema se comporta como deveria


como testar?testes manuais.testes automatizados.


testes manuais


$ão caros$ requer pessoal qualificado

$ requer tempo

$ requer documentação

$ repetitivos e cansativos


o que aprendemos com desenvolvimento de software é que...


tudo que depende do homem e é repetitivo está sujeito a

falhas


por isso nós

automatizamos! :-)


testes automatizados


um programinha para testar outro programinha


testes te trazem confiança e segurança para...

> implementar novas features> achar e corrigir bugs> refatorar código> refatorar código dos outros


CONFIANÇA


os testes te permitem ter...

> menor incidência de bugs> feedback rápido do que funciona> regressão de código> produtividade> melhor design do código> documentação executável


tipos de testes testes de unidade testes de integração testes de aceitação


testes de unidademenor unidade de código

executável


menor unidade na

POO= método


teste de unidade

= teste unitário


> mais fáceis de escrever;> muito rápidos para rodar;> mais fáceis para rastrear erros;

testes de unidade normalmente são:


que tal rodar centenas ou milhares de testes em

segundos?


feedback quase que instantâneo! WOW!


testes de integraçãoseu código integrado ao banco

de dados, rede, disco etc


valida os componentes de software funcionando juntos


valida os componentes de software funcionando juntos

Yuri Adams

teste de “maxu” vai no banco de dados!


e assim como os testes de unidade...


> mais fáceis de escrever;> muito rápidos para rodar;> mais fáceis para rastrear erros;

testes de integração normalmente são:


feedback AINDA quase que instantâneo


testes de aceitaçãoo que o usuário espera que

aconteça


teste


endteste


endto

teste


end

endto

teste


valida o software na perspectiva do usuário


valida o software na perspectiva

do usuário


> trabalhosos para escrever;> lentos para rodar;> difíceis para rastrear erros;> frágeis

testes de aceitação normalmente são:


apesar da dificuldade para escrevê-los...


Handerson Frota


Aceite os testes de aceitação!!


ainda assim vale a pena!

Aceite os testes de aceitação!!

Handerson Frota



resumindo...


como tudo isso vai numa app real?


browser

app(servidor)

banco de dados


teste de unidade


teste de integraçãoTuesday, October 18, 2011

teste de aceitação


teste de integração

teste de unidade

teste de aceitação


qual o melhor?


unidade > integração ?


nãoTuesday, October 18, 2011

integração > aceitação ?


aceitação > unidade ?


depende?


simTuesday, October 18, 2011

depende da tua necessidade


depende da tua necessidadeteste de aceitação testa TUDO.

Handerson Frota


depende da tua necessidadeteste de aceitação testa TUDO.

Handerson Frota

Yuri Adams

teste de integração é teste de “maxu”.


mas no geral, siga a pirâmide


Aceitação - 10%

Integração - 40%

Unidade - 50%

Test Automation Pyramid


que tal um pouco de prática, né?


de maneira não automatizada


problema:calcular fatorial de um

número

4! = 4.3.2.1 = 24


1! ==> 12! ==> 23! ==> 6

...


4! = 4.3.2.1 = 24

“com um algoritimo recursivo eu

resolvo isso fácil antes da novela das

7h”


Uma função recursiva é uma função que se refere a si própria


como testar o código?


1! ==> 12! ==> 23! ==> 6

...


você escreve uma classe de teste “meia-boca”


depois roda a classe de teste na linha de comando


depois roda a classe de teste na linha de comando

para ver o resultado!Tuesday, October 18, 2011

você testa mais um pouco...


e roda mais uma vez para ver o resultado...


altera mais um pouco,roda mais um pouco,verifica o resultado,

corrige aqui, corrige ali,roda de novo, ...


e depois que tudo funciona como

esperado...


zipa e envia pro professor, né?



ainda não!!Tuesday, October 18, 2011


falta apagar a classe “meia-boca” de teste!


agora sim! zipa e envia pro professor!


agora sim! zipa e envia pro professor!

Sérgio

com cópia pra mim também! ;D


PRONTO!


facinho, né?


agora você pode jogar Starcraft II em paz!


ou


jogar XBox com seus amigos descolados


eu me pergunto...


e depois de todo esse esforço...



você DESCARTA sua classe de teste?



Sérgio

e daí?





Sérgio

e daí?o que importa é o programa rodando!




Sérgio

e daí?o que importa é o programa rodando!

nunca mais vou mexer nesse código de novo mesmo


mas na vida real não é bem assim...


você mantém o código até que o software

“morra”


um software não morre...



até que



até quevocê tire ele de produção,




você apague todo o código fonte





você apague o banco de dados





você mate os programadores,

mate os analistas e o arquiteto






você mate os programadores,

mate os analistas e o arquiteto


e você queime o backup e documentação


mas pro seu azar...


suponha que seu professor queira um algoritimo não-recursivo


suponha que seu professor queira um algoritimo não-recursivo

#comofas


1. você vai ter que estudar o problema de novo


2. você tem que alterar o código atual de novo


3. você vai ter que testa-lo de novo


mas cadê minha classe de teste?


eu apagueeeeeiiii?


que tal fazermos do jeito certo?


que tal fazermos do jeito certo?

com testes automatizados


jUnitassertEquals(expected, actual);


jUnitassertEquals(4, 2+2);


jUnitassertEquals(7, 10-4);


vamos testar


implementação recursiva


1! ==> 1

primeiro caso de teste


você escreve o teste com jUnit


depois roda o teste...


2! ==> 23! ==> 6

4! ==> 24 5! ==> 120

mais alguns casos de teste...


escreva os casos de teste...


roda mais uma vez...


0! ==> 11! ==> 1

um caso esquecido...


não me escapa...


roda mais uma vez...


PRONTO!agora você pode escrever o

algoritimo não-recursivo


#greenbarrefatora ==> roda os testes


facinho, né?


primeiro escreve o código da implementação, depois escreve o de

teste... LEGAL!


e se fosse possível escrever o teste ANTES da implementação?


ahn?


TDDTest Driven Development



é assim que eu evoluo minha aplicação de forma contínua



é assim que eu evoluo minha aplicação de forma contínuaeu falei sobre isso aqui ontem, ué!


step by step


TDD = testes


TDD = testesnãoTuesday, October 18, 2011

TDD é sobre DESIGN e MODELAGEM de código


a bateria de testes é um brinde


CULTURA DE TESTEScasos e casos


NEM TUDO SÃO FLORESDepois de +2 anos escrevendo testes.


primeiro passo na consultoria


Convencer a gerência.Seria um investimento de médio-longo prazo.


Projeto já em andamento.Dificuldade para escrever testes.


Infra?Não tínhamos nada pronto!


Colaboração da equipe.Equipe de bons desenvolvedores, mas sem

experiência com testes.


Tuesday, December 15, 2009

Zona de Conforto


Devs. simpatizantes.Teste de integração é teste de “maxu”!


Testes mal escritos.Você vai escrevê-los, pode ter certeza disso.


TDD.Somente em regras de negócio complexas.


OOP e SOLID PrinciplesSem estes conhecimentos não é tão simples ter

um bom design.


Testes de Aceitação.Tudo ia bem, até o dia em que o número de testes cresceu demais.


Testando cenários importantes.

Começamos do jeito certo.


Aceitação - 10%

Integração - 40%

Unidade - 50%

Test Automation Pyramid


More, more...Testes com granularidade fina demais.


Integração - 30%

Unidade - 40%

Aceitação - 30%

Test Automation Pyramid Square


Mantê-los se tornou caro.Frágeis, feedback demorado, falsos negativos e difícil rastrear erros.


Nos tornamos mais criteriosos.


IMPACTODepois de +2 anos escrevendo testes.


PRODUTIVIDADE.Baixa no início. Melhora durante os Sprints.


Qualidade no software. Menor incidência de bugs e correções rápidas.


De 100% para 25%.Melhoramos nossas estimativas.


Gerência.Satisfeita com a produtividade de alguns

projetos, decepcionada com outros.


Equipe mais madura.Perceberam a importância real dos testes.


CONCLUSÃO


Você só percebe os benefícios dos testes entre

6 meses e 1 ano


não existe uma receita de bolo para desenvolver software


mas simum conjunto de princípios e

práticas que podem te ajudar a desenvolver melhor


permita que sua equipe trabalhe melhor


permita que sua empresa entregue software melhor


permita-se ser um profissional melhor


use testes automatizados


testes automatizados

eu aprovo!Tuesday, October 18, 2011

Rafael [email protected]


mailto:[email protected]

mailto:[email protected]

importancia dos testes automatizados

Documents