Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Desenvolvimento dirigido por comportamento e por teste

20 views

Published on

Oficina estilo Dojo sobre desenvolvimento dirigido por comportamento e por teste na 15° Seminfo - Unit

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Desenvolvimento dirigido por comportamento e por teste

  1. 1. DOJO: Desenvolvimento Orientado a Objetos Dirigido por Comportamento e Teste PROF. ME. FABIO GOMES ROCHA
  2. 2. Quem sou eu? Professor da Unit a 5 anos +23 anos de experiência (mercado) e 22 como professor Scrum Master e Scrum Master Professional – Scrum Alliance Certificado Exin ISO 27001 Foundation Membro da Scrum Alliance a 6 anos Mestre em Ciências da Computação - UFS Líder do GPITIC Líder do Agile Sergipe Doutorando em educação Unit
  3. 3. O que é TDD? TDD (Test Driven Development – Desenvolvimento Guiado por testes) O desenvolvimento orientado a testes ou guiado por testes foi proposto, inicialmente, por Kent Beck como parte da metodologia XP (Extreme Programming) (Pedroso in Prikladnicki, Willi, Milani; 2014) e tem como objetivo código limpo e que funcione (Beck, 2010). Conforme Back “se testar é bom, todos vão testar o tempo inteiro (testes de unidade), até mesmo os clientes (testes funcionais)”(p. 10, 2008). Conforme Lopes “[...]TDD é uma forma de testar meu software antes de tê-lo pronto e não apenas criar testes. Com TDD validamos não somente se há um erro de lógica no código e sim se os requisitos estão bem definidos para que possamos entregar aquilo que é esperado”(p. 63, 2012). Conforme Freeman e Price(2012, p. 5) “ Você não tem nada a perder, a não ser os seus bugs”
  4. 4. O que é TDD? TDD (Test Driven Development – Desenvolvimento Guiado por testes) Conforme Mike Cohn o TDD é uma prática inestimável, isso por que ele farante que nenhum código não testado entre no sistema. Assim, pode-se considerar que o TDD é uma prática de projeto e de programação.(Cohn, 2011). A Microsoft produziu dois estudos e descobriu que o numero de erros encontrados diminui entre 20% a 38% com o uso do TDD(Sanchez, Williams e Maximilien, 2007)
  5. 5. CICLO TDD O ciclo do TDD é: Escrever um teste, escrever algum código para fazê-lo funcionar, refatorar o código para que seja tão simples quanto uma implementação dos recursos testados, repita. (FREEMAN, PRICE, p. 6, 2012)
  6. 6. Conceitos fundamentais para TDD Teste automático: a automação de teste é uma característica fundamental para a prática. Além de que os testes devem ser pequenos, concisos, independentes e rápidos; Regressão: este é um dos aspectos mais importantes de automatizar testes pois permite um reteste após mudanças no sistema; Cobertura: medir a quantidade de códigos com teste; Refatorar: processo de melhoria de um sistema, sem que este perca a funcionalidade, ou seja, mudamos a estrutura, porém sem que se altere o comportamento; Design, não teste: os testes automatizados são mais efetivos do que os manuais, na verificação de unidades de códigos, visando assim garantir a qualidade do sistema. Porém no TDD os testes funcionam mais como foco de melhoria e design do sistema, auxiliando assim para o processo de concepção do design da solução. Predroso, 2012.
  7. 7. Ciclo TDD 1. Criar o teste; 2. Executar todos os possíveis testes e ver a aplicação falhar; 3. Escrever a aplicação para os testes passarem; 4. Re-executar todos os possíveis testes e ver se todos estão passando; 5. Refatorar; 6. Executar os testes novamente, garantindo que eles continuem passando.
  8. 8. Junit: Introdução a ferramenta Os Xunit´s são frameworks que permitem o teste unitário, o Junit é um destes frameworks. Este framework basicamente emprega a reflexão para caminhar pela estrutura das classes e encontrar uma que represente um teste (FREEMAN, PRYCE, 2012), um teste Junit invoca o objeto sob teste e depois faz uma asserção sobre os resultados usando métodos de asserção definidos pelo Junit, os quais geram mensagens de erro úteis quando eles falham. ◦ @Teste  Identifica que a função é de teste ◦ SetUp()  Roda antes do teste; ◦ tearDown()  roda depois do teste; ◦ assertTrue()  Verifica se é verdadeiro ◦ assertEquals()  Verifica igualdade ◦ assertSame()  Verifica se os objetos são iguais
  9. 9. Contexto do primeiro teste Entenda o problema Rascunhe o projeto (Arquitetura) Automatize: *monte, *Distribua, *Teste de ponta a ponta Escreva um teste de aceitação falho Escreva um teste de unidade falho Torne o teste bem- sucedido Refatore
  10. 10. BDD “O desenvolvimento guiado por comportamento é o desenvolvimento guiado por testes feito corretamente” O BDD foi criado por Dan North, aproximadamente nos anos de 2003 não como uma nova metodologia, mas sim, uma forma de integrar o TDD no desenvolvimento de software integrando-se as regras de negócio. https://dannorth.net/introducing-bdd/
  11. 11. Ciclo BDD
  12. 12. BDD O BDD é um conjunto de práticas de engenharia de software que visa ajudar equipes a criar e entregar software de valor e com qualidade com maior rapidez, para tanto o BDD emprega questionamentos sobre o comportamento de uma aplicação antes e durante o desenvolvimento. Assim, o BDD baseia-se em práticas ágeis e enxutas, incluindo, em particular, o Desenvolvimento Orientado a Testes (TDD) e o Design Dirigido por Domínio (DDD, Domain- Driven Design). Porém, o mais importante é que o BDD fornece uma linguagem comum baseada em sentenças simples e estruturadas expressas em inglês (ou no idioma nativo dos interessados) que facilitam a comunicação entre os membros da equipe do projeto e os participantes do negócio.
  13. 13. BDD Em BDD os documentos de requisitos são as histórias de usuário. As histórias de usuários se concentram no comportamento desejável, assim, ao invés de preocupar-se com a implementação, analisamos o comportamento desejado, reduzindo assim mal-entendido entre os stakeholders. Uma história de usuário deve ser testável, ser pequena o suficiente para ser implementada em uma iteração e possuir valor para o negócio, ou seja: especifico, mensurável, realizável, relevante e com duração fixa.
  14. 14. história de usuário Como [função do keyuser] Eu quero/de modo que [ o que se deseja fazer] Para que [tarefa desejada] Exemplo: ◦ Como um gestor de RH ◦ Eu quero calcular o INSS dos funcionários ◦ Para que eu possa emitir a folha de pagamento com seus devidos descontos
  15. 15. BDD Assim, o BDD enfatiza o trabalho com os stakeholders para definir o comportamento do sistema em desenvolvimento. As histórias de usuário são artifícios que facilita a comunicação com os stakeholders na criação de requisitos; Cara uma das histórias de usuário ficam em cartões de forma que facilite o seu desenvolvimento.
  16. 16. Cenário Cada história de usuário pode ter um ou mais cenários. Dado = Given When = Quando Then = Então Ciclo: Passou, Falhou, Skypped, pending e undefined
  17. 17. Junit: Introdução a ferramenta Dicas do Lopes(2012) para construir um bom teste: 1. Deve ser específico, objetivo e focado, ou seja, nada de um teste unitário testando coisas demais. Alta coesão é o que você precisa alcançar; 2. Princípio básico, mas que queira repetir. Nada de um teste unitário que dependa de outro, eles são únicos e para executar não pode depender de outro teste; 3. Refatorados. O código no teste unitário deve ser tão legível quanto seu código funcional; 4. Rápido. Ele precisa rodar muito rapidamente. Um teste unitário lento vão impactar na sua execução, pois quanto mais lento for, menos vezes você vai executá-lo; 5. Os nomes devem ser claros e específicos, por exemplo: testeValidandoINSS(); 6. Testes unitários devem ser legíveis.
  18. 18. Problema folha de pagamento Você esta desenvolvendo um sistema que deve calcular os descontos e o salário liquido do funcionário, para tanto, temos as seguintes regras: Salário de Contribuição Alíquotas (%) até 1.693,72 8,00 de 1.693,73 até 2.822,90 9,00 de 2.822,91 até 5.645,80 11,00
  19. 19. Problema folha de pagamento Você esta desenvolvendo um sistema que deve calcular os descontos e o salário liquido do funcionário, para tanto, temos as seguintes regras: Base de cálculo mensal em R$ Alíquota % Parcela a deduzir do imposto em R$ De 1.903,99 até 2.826,65 7,5 142,80 De 2.826,66 até 3.751,05 15,0 354,80 De 3.751,06 até 4.664,68 22,5 636,13 Acima de 4.664,68 27,5 869,36

×