ci&t spin – campinas - 2009 equipe de testes em projetos com ci e tdd
TRANSCRIPT
Gabriela PatuciExperiência de 5 anos em Testes de SoftwareAnalista de Testes na Ci&T CampinasFormada em TI pela UNICAMPCursando disciplinas de mestrado na UNICAMP
AgendaCI – O que é?
CI – Benefícios
CI – Por que usar?
CI – Exemplo de Fluxo de Atividades
TDD – O problema
TDD – Testes Tradicionais X TDD
TDD – Como fazer?
TDD – Correção de Bugs
Dúvidas
Referências
CI (Continuous Integration)
CI (Continuous Integration)
O que é?
Prática do Desenvolvimento de Software onde os membros do time integram seu trabalho frequentemente (várias integrações diárias). Cada integração é verificada em uma build automática (incluindo testes) para detectar erros de integração o mais rápido possível.
CI (Continuous Integration)
Benefícios
• Redução de riscos;• Maior facilidade para encontrar e remover erros;• Feedback mais rápido para novas features;• Ambiente mais colaborativo no ciclo de desenvolvimento;
CI (Continuous Integration)
Por que usar?
•Mantém um único repositório do código;•Automatiza a build;•Todo mundo faz commit todo dia;•Mantem a build rápida;•Testes feitos num clone do ambiente de produção; •Fica fácil para qualquer um ter a última versão executável;•Todos podem ver o que está acontecendo;•Desenvolvimento automatizado.
CI (Continuous Integration)
Exemplo de Fluxo de Atividades:
1. O desenvolvedor cria o código.
2. Comita o código.
3. Um script procura por todo o código comitado, gera uma build e a instala na CI Machine. Durante este processo, os testes unitários são rodados.
4. Se tudo estiver ok, o engenheiro deve adicionar uma tag ao arquivo (QA tag), senão, corrigir o código e voltar ao passo 2.
CI (Continuous Integration)
Exemplo de Fluxo de Atividades:
5. Um push no ambiente de QA (QA build) é feito automaticamente ao fim do dia, ou quando for solicitado. Um script procura por todos os arquivos comitados e com a QA tag e gera a build.
6. Após a build ser gerada, solicita-se a um QA Engineer para instalar a build no ambiente de QA.
7. Depois da instalação, o QA Engineer pode começar seus testes.
8. Se bugs (P1 or P2) forem abertos, eles devem ser corrigidos durante a sprint. Se tudo estiver ok, a última QA build pode ser instalada em produção.
No entanto, com a Atividade de Testes...
- Mais barato,- Mais rápido, - Melhor!
TDD (Test Driven Development)
Como Fazer?
- Design : Descobrir o que vc realmente precisa. - Testes : Escreva um teste que expresse o que foi decidido na etapa de Desing.- Implementação : Escreva o código. - Testes : Rode o teste criado. Este teste DEVE passar.
TDD (Test Driven Development)
Escreva uma vez, Rode muitas!
- Escreva os testes, - Guarde em local de fácil acesso, - Rode frequentemente (um click), - Não devem ter mais interferência,- Armazene os resultados (logs).
TDD (Test Driven Development)
TDD em Correção de Bugs
- Pegue um pedaço de código (que está quebrando), - Crie um teste no qual ele deva passar (baseado nos requisitos), - Rode o teste (este teste NãO vai passar), - Corriga o código para passar neste teste, - Rode o teste novamente (agora SIM!)
TDD (Test Driven Development)
http://www.slideshare.net/Skud/test-driven-development-tutorial - Kirrily Robert
http://hudson-ci.org/
www.cit.com.br
www.ciandt.com
Referências