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...


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


@yuriadams
O 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


testar

por que testar?


para veriﬁcar se o sistema se
comporta como deveria


como testar?
testes manuais.
testes automatizados.


testes manuais


$ão caros
$ requer pessoal qualiﬁcado
$ 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! :-)


um programinha para testar
outro programinha


testes te trazem conﬁanç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 unidade
menor unidade de código
executável


menor
unidade na = método
POO


teste de teste
=
unidade unitário


testes de unidade
normalmente são:

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


que tal rodar centenas ou
milhares de testes em
segundos?


feedback quase que instantâneo!
WOW!

seu código integrado ao banco
de dados, rede, disco etc


valida os componentes de
software funcionando juntos


valida os componentes de
software funcionando juntos
teste de “maxu” vai no banco de
dados!

Yuri Adams

e assim como os testes
de unidade...

normalmente são:

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


feedback AINDA quase que
instantâneo


o que o usuário espera que
aconteça


teste


teste
end


teste
end
to

teste
end
to
end

valida o software na perspectiva
do usuário


valida o software na perspectiva

do usuário


normalmente são:

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


apesar da diﬁculdade para escrevê-los...



Aceite os testes de
aceitação!!

Handerson Frota



Aceite os testes de
aceitação!!

ainda assim
vale a pena!
Handerson Frota


resumindo...


como tudo isso vai numa app
real?


browser

banco de dados
app
(servidor)


teste de unidade


teste de integração

teste de aceitação


teste de unidade

teste de aceitação

teste de integração

qual o melhor?


unidade > integração ?


não

integração > aceitação ?


aceitação > unidade ?


depende?


depende da tua
necessidade


depende da tua
necessidade
teste de aceitação testa TUDO.

Handerson Frota

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

depende da tua Yuri Adams

necessidade
teste de aceitação testa TUDO.

Handerson Frota

mas no geral, siga a
pirâmide


Test Automation Pyramid

Aceitação - 10%

Integração - 40%

Unidade - 50%


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! ==> 1
2! ==> 2
3! ==> 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?


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!

você testa mais um pouco...


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


altera mais um pouco,
roda mais um pouco,
veriﬁca o resultado,
corrige aqui, corrige ali,
roda de novo, ...


e depois que tudo
funciona como
esperado...


zipa e envia pro
professor, né?


zipa e envia pro
professor, né?

ainda não!!

zipa e envia pro
professor, né?

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

agora sim! zipa e envia
pro professor!


agora sim! zipa e envia
pro professor!

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

Sérgio

PRONTO!


facinho, né?


agora você pode jogar
Starcraft II em paz!

jogar XBox com seus amigos
descolados


eu me pergunto...


e depois de todo esse
esforço...


esforço...

você DESCARTA sua
classe de teste?

esforço...
e daí?

Sérgio
você DESCARTA sua
classe de teste?

esforço...
o que importa é o programa
e daí?
rodando!

Sérgio
você DESCARTA sua
classe de teste?

esforço...
o que importa é mexer nesse
nunca maisevou o programa
daí?
códigorodando! mesmo
de novo

Sérgio
você DESCARTA sua
classe de teste?

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é que
você tire ele de produção,


até que
você apague todo o código fonte


até que
você apague o banco de dados


até que
você mate os programadores,
mate os analistas e o arquiteto


até que
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

#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


jUnit
assertEquals(expected, actual);


jUnit
assertEquals(4, 2+2);


jUnit
assertEquals(7, 10-4);


vamos testar

implementação recursiva

primeiro caso de teste

1! ==> 1


você escreve o teste com jUnit


depois roda o teste...


mais alguns casos de teste...

2! ==> 2
3! ==> 6
4! ==> 24
5! ==> 120


escreva os casos de teste...


roda mais uma vez...


um caso esquecido...

0! ==> 1
1! ==> 1


não me escapa...


PRONTO!
agora você pode escrever o


#greenbar
refatora ==> roda os testes


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?


TDD
Test Driven Development


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

TDD


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

TDD


step by step


TDD = testes


não
TDD = testes


TDD é sobre DESIGN e
MODELAGEM de código


a bateria de testes é
um brinde


CULTURA DE TESTES
casos e casos


NEM TUDO SÃO FLORES
Depois 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.


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 Principles
Sem 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.


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


Test Automation Pyramid
Square

Aceitação - 30%

Integração - 30%

Unidade - 40%


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


Nos tornamos mais
criteriosos.


IMPACTO
Depois 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 sim
um 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 proﬁssional
melhor


use testes
automatizados



eu aprovo!

Rafael Ponte
rponte@triadworks.com.br


Importancia dos testes automatizados

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von secomp2011

Mehr von secomp2011 (6)

Importancia dos testes automatizados