Workshop Agile tdd - Test Driven development

Apresentação em tema: "Workshop Agile tdd - Test Driven development"— Transcrição da apresentação:

1 Workshop Agile tdd - Test Driven development
31/05/2016

2 AGENda Assuntos: Conceito Ciclo de Desenvolvimento Siglas relacionadas
Context Driven Test Ferramentas

3 TDD - Conceito TDD é o desenvolvimento de software orientado a testes, Test Driven Development. Foi criado por Kent Beck, engenheiro de software americano criador do Extreme Programming. Beck foi um dos 17 signatários originais do Agile Manifesto em 2001. Basicamente o TDD se baseia em pequenos ciclos de repetições, onde para cada funcionalidade do sistema um teste é criado antes. Em seguida, é implementada a funcionalidade para fazer o teste passar! Simples assim! Mas mais do que simplesmente testar seu código, TDD é uma filosofia, uma cultura: significa começar com o fim na mente.

4 TDD Ciclo de desenvolvimento Red, Green, Refactor. Ou seja:
Escrevemos um Teste que inicialmente não passa (Red) Adicionamos uma nova funcionalidade do sistema Fazemos o Teste passar (Green) Refatoramos o código da nova funcionalidade (Refactoring) Escrevemos o próximo Teste Desenvolvedores normalmente usam Frameworks de testes, como xUnit, para criar e executar automaticamente uma série de casos de teste. Através de TDD, programadores podem aplicar o conceito de melhorar e depurar código legado desenvolvido a partir de técnicas antigas. Ciclo de desenvolvimento do TDD

5 TDD 1. Adicione um teste: Cada nova funcionalidade inicia com a criação de um teste. Este teste precisa inevitavelmente falhar porque ele é escrito antes da funcionalidade a ser implementada. Para escrever um teste, o desenvolvedor precisa claramente entender as especificações e requisitos da funcionalidade presentes nos  casos de uso ou user stories .O desenvolvedor foca nos requisitos 'antes' do código, que é uma sutil mas importante diferença. 2. Execute todos os testes e veja se algum deles falha: Esse passo valida se todos os testes estão funcionando corretamente. Isto aumenta a confiança que se está testando a coisa certa, e que o teste somente irá passar nos casos intencionados. 3. Escrever código O próximo passo é escrever código que fará o teste passar. O novo código escrito até esse ponto poderá não ser perfeito e pode, por exemplo, passar no teste de uma forma não elegante. Isso é aceitável porque posteriormente ele será melhorado. O importante é que o código escrito deve ser construído somente para passar no teste; nenhuma funcionalidade (muito menos não testada) deve ser predita ou permitida em qualquer ponto. 4. Execute os testes automatizados e veja-os executarem com sucesso Se todos os testes passam agora, o programador pode ficar confiante de que o código possui todos os requisitos testados. 5. Refatorar código: Nesse ponto o código pode ser limpo como necessário. Ao re-executar os testes, o desenvolvedor pode confiar que a refatoração não é um processo danoso a qualquer funcionalidade existente. Um conceito relevante nesse momento é o de remoção de duplicação de código. 6. Repita tudo Iniciando com outro teste, o ciclo é então repetido, empurrando a funcionalidade a frente. O tamanho dos passos deve ser pequeno - tão quanto de 1 a 10 edições de texto entre cada execução de testes. A Integração contínua ajuda a prover pontos reversíveis.

6 TDD Siglas Relacionadas: ATDD - Acceptance Test-driven Development
CDT - Context Driven Testing BDD - Behavior Driven Development DDD - Domain-Driven Design SBE - Specification By Example

7 TDD

8 TDD BDD

9 TDD BDD

10 aTDD - Acceptance Test-Driven Development

11 TDD - Ferramentas Xunit: Junit, PHPUnit: automação dos testes unitários; Selenium WebDriver: automação de testes; Jenkins: Integração contínua– integra com Selenium, Test Link e xUnit;

12 TDD - referências http://tableless.com.br/tdd-por-que-usar/

13 FIM