Curso Online de Test Driven Development

introdução ao desenvolvimento orientado a testes (test-driven development - tdd)

tdd é uma técnica de desenvolvimento de software cujo processo é formado por pequenas iterações para o desenvolvimento de uma nova funcionalidade, começando pela implementação de um caso de teste, depois pelo código necessário para fazer o teste passar, e finalmente pela refatoração do código visando melhor acomodar as mudanças feitas.
não é um método para testar software, mas para construir software.
tdd vem do conceito de “test-first programming” do xp (extreme programming), mas acabou ganhando tanto interesse, que hoje tem sido adotado independente do xp e das técnicas de programação ágil;

introdução

página 2

objetivo do tdd:
“clean code that works”
código limpo que funciona
“mantra” do tdd: vermelho-verde-refatorar
codifique o teste;
faça ele compilar e executar (não deve passar - vermelho);
implemente o requisito e faça o teste passar (verde);
refatore o código;

introdução

página 3

garante a existência de testes unitários completos e atualizados, que:
eliminam o medo de alterarmos alguma coisa que funciona (testada manualmente), e acabarmos introduzindo algum problema;
nos permite utilizar refatoração (substituir uma implementação por outra equivalente) de forma muito mais agressiva devido à facilidade dos testes verificarem o resultado.
diminui a quantidade de erros por linha de código (código-fonte de mais qualidade)
testes unitários servem como especificação de como os componentes do sistema funcionam;
nos leva a produzir componentes de software mais desacoplados, para garantir o isolamento dos testes, o que acaba favorecendo o projeto do sistema.

principais benefícios do tdd

página 4

a metodologia tdd
estudo de caso: aplicação do tdd na ibm
construção de casos de testes com nunit
considerações finais

organização da apresentação

página 5

a metodologia tdd baseado principalmente em kent beck test-driven development by example, 2003

página 6

testes de unidade: testa uma unidade mínima do software;
testes de integração: testa a comunicação entre os módulos;
testes de sistema: testa todo o sistema para verificar se atende aos requisitos;
testes de integração de sistema: testa a comunicação do sistema com outros sistemas com os quais interage;
testes de aceitação: testes realizados pelo usuário final para verificar se o sistema faz o que ele espera;

tipos de testes

página 7

a metodologia tdd é conduzida através dos “testes do programador”.
frequentemente esses testes são chamados de “teste de unidade”, mas esse nem sempre é o caso (pode ser teste de integração).
é importante destacar que não se trata dos testes de sistema (caixa preta) nem os de aceitação (feitos pelo usuário final)

tipos de testes

página 8

a “espiral da morte” do teste

página 9

o ciclo mortal do “estou sem tempo para testar”:

1. construa testes isolados uns dos outros
um caso de teste não deve depender do sucesso de outro para funcionar;
deve ser possível executar um caso de testes isoladamente, sem executar nenhum outro;
2. comece definindo uma “test list”
de modo geral para uma mesma classe ou método a ser testado, existirão diferentes casos de teste. liste-os primeiro (brain-storm);
provavelmente ao longo do desenvolvimento você adicionará novos casos de teste à lista;

princípios

página 10

mas o que testamos?
fluxos condicionais (ifs, switches, etc.)
polimorfismos
loops
operações
etc..

princípios

página 11