Ci&T SPIN – Campinas Equipe de testes em projetos com CI e TDD

Gabriela Patuci Experiência de 5 anos em Testes de Software Analista de Testes na Ci&T Campinas Formada em TI pela UNICAMP Cursando disciplinas de mestrado na UNICAMP

Agenda CI – 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)

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.

TDD (Test Driven Development) Barato Bom Rápido O Problema

NO SILVER BULLET TDD (Test Driven Development)

No entanto, com a Atividade de Testes... - Mais barato, - Mais rápido, - Melhor! TDD (Test Driven Development)

Apenas com Testes Tradicionais: Design Implementação Teste TDD (Test Driven Development)

Usando TDD: Design Implementação Testes 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)

Correção de BUGS Abertura de Bugs Correção dos Bugs Testes 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)

- Kirrily Robert Referências

? Dúvidas

Obrigado! Ci&T is a symbol of innovation in outsourcing

Copyright (C) Ci&T Software S.A. – Todos os direitos reservados. Todos os nomes e produtos são usados apenas com o propósito de identificação e são marcas registradas de seus respectivos proprietários.