METODOLOGIAS ÁGEIS TESTES UNITÁRIOS

METODOLOGIAS ÁGEISTESTES UNITÁRIOS

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

Porque devemos testar?

• Como desenvolvedores devemos buscar sempre a qualidade máxima do que escrevemos.

• Em um código testado, deixamos aos próximos desenvolvedores que forem trabalhar nesse fonte como herança a segurança.

• Testes unitários servem como documentação, no que tange a impactos.

• Reduzimos o retrabalho, erros uma vez descobertos são catalogados e não voltam a acontecer.

• Um sistema de testes automatizados logicamente executa mais testes em menos tempo do que um “tester”.

• Testes unitários nos ajudam manter a visão e o foco no que foi projetado.

Além disso....

Alguns Bugs Históricos• 1987 – Segunda feira negra – Por um erro no sistema todas as

bolsas mundiais foram afetadas, e num único dia o índice Dow Jones perdeu 22,6% e o S&P 20%. Ainda hoje esta é a maior perda diária em Wall Street num único dia.

• 1991 – Misseis Patriots – Um erro de arredondamento em uma versão do software de gestão, resultou em uma base americana totalmente destruída além de 28 militares mortos.

• 1996 – Ariane 5 voo 501 - Durante o lançamento a tentativa de encaixar um número de 64 bits dentro de um “espaço” de 16-bits fez com quem o computador principal e de backups crashassem (utilizavam o mesmo software). Resultado, o foguete autodestruiu-se, mandando para o lixo um investimento de 8 milhões de dólares e mais 500 milhões em satélites.

• 2003 – Apagão na américa do norte – 55 milhões de pessoas ficaram sem luz por que uma estação de geração ficou off-line.

• Os estados unidos estimam que bugs de software lhe custem aproximadamente 60 bilhões de dólares por ano...

Porque não testamos?

• Testar sai caro e por algum motivo os gestores preferem pagar todo mês uma pessoa para fazer o trabalho de um sistema de testes automatizados.

• Dificuldades ao iniciar os testes, escrever uma funcionalidade que seja testada unitariamente demanda uma fase de analise e desenvolvimento maior.

• Problema na organização de cronograma dos projetos. Geralmente quando um cronograma está apertado, a primeira coisa que é cortada é a fase de testes unitários.

• Resistência a mudança de cultura, pessoas tem enorme dificuldade quando o assunto é sair da zona de conforto. Reciclar-se é algo inerente a nossa atividade, e infelizmente alguns profissionais não fazem isso.

Ciclo do TDD• 1 – Escreva um teste: Deve ser escrito um teste que

falhe, a partir do “Setup” de um cenário devidamente projetado. Neste momento os testes falharão.

• 2 – Implementando o código: Nesse momento a implementação/alteração deverá ser feita e os testes devem estar funcionando.

• 3 – Refatorando o código: Aqui efetuamos a refatoração do código, o objetivo nesta etapa é eliminar redundâncias de fonte e melhorar a sua qualidade como um todo. Aqui os testes devem funcionar.

Escrevendo Testes

Entre várias técnicas e frameworks para escrever testes, hoje será mostrado:

•Dunit (Framework para testes unitários em Delphi);•Objetos Mock (Objetos Duble);

DUnit

DUnit é um framework de testes Xtreme para programas Borland Delphi. Ele foi originalmente inspirado no JUnit quadro escrito em Java por Kent Beck e Erich Gamma, mas evoluiu para uma ferramenta que usa muito mais do potencial do Delphi para ser muito mais útil para desenvolvedores.

Objetos Mock (Objeto Duble)

As vezes para criar testes unitários é necessário simular o comportamento de objetos complexos através dos mocks, são muito úteis quando os objetos reais são difíceis de criar ou impossíveis de serem incorporados no teste de unidade. Neste caso, em vez de usar o objeto real, usa-se um mock object que simula o seu comportamento.

E finalmente..... Vamos Praticar...

Indicações • Código Limpo (Robert C. Martin);• Test Driven Development Teste e Design no Mundo Real

(Mauricio Aniche);• Desenvolvimento de Software - Orientado a Objetos

Guiados Por Teste (Steve Freeman e Nat Pryce);• Programador Pragmático (Andrew Hunt e David Thomas);

“...você não tem nada a perder, a não ser os seus bugs”Steve Freeman

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