WORKSHOP AGILE TDD TEST DRIVEN DEVELOPMENT 31052016 AGENDA

WORKSHOP AGILE TDD - TEST DRIVEN DEVELOPMENT 31/05/2016

AGENDA Assuntos: 1. Conceito 2. Ciclo de Desenvolvimento 3. Siglas relacionadas 4. Context Driven Test 5. Ferramentas

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.

TDD 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 x. Unit, 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

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 claramentender 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.

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

TDD

TDD BDD

TDD BDD

ATDD - ACCEPTANCE TEST-DRIVEN DEVELOPMENT

TDD - FERRAMENTAS Xunit: Junit, PHPUnit: automação dos testes unitários; Selenium Web. Driver: automação de testes; Jenkins: Integração contínua– integra com Selenium, Test Link e x. Unit;

TDD - REFERÊNCIAS http: //tableless. com. br/tdd-por-que-usar/ http: //www. slideshare. net/smithcdau/40 -agile-methods-in-40 -minutes-56693089 https: //pt. wikipedia. org/wiki/Test_Driven_Development http: //www. devmedia. com. br/tdd-fundamentos-do-desenvolvimento-orientado-a-testes/28151 http: //eduardopires. net. br/2012/06/ddd-tdd-bdd/

FIM