[GUTS-RS] Práticas de desenvolvimento aplicadas na automação de testes com Selenium
•Transferir como PPTX, PDF•
1 gostou•1,649 visualizações
Este documento resume uma palestra sobre práticas de desenvolvimento aplicadas na automação de testes com Selenium. A palestra abordou tópicos como a importância dos testes automatizados, linguagens orientadas a objetos, abstrações, princípios SOLID, DRY, design patterns, clean code e organização de testes. A palestra também discutiu ir além dos testes com Selenium explorando livros e ferramentas adicionais.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a [GUTS-RS] Práticas de desenvolvimento aplicadas na automação de testes com Selenium
Semelhante a [GUTS-RS] Práticas de desenvolvimento aplicadas na automação de testes com Selenium (20)
Mais de GUTS-RS
Mais de GUTS-RS (15)
Último
Último (6)
[GUTS-RS] Práticas de desenvolvimento aplicadas na automação de testes com Selenium
- 1. #gutsrs /@gutsrs Práticas de desenvolvimento aplicadas na automação de testes com Selenium Robson Bittencourt
- 2. Programação • 19h15 às 19h45 Recepção, boas vindas e Coffee para integração • 19h45 às 19h55 Abertura do evento, apresentação do GUTS-RS e expectativas do evento • 19h55 às 20h45 Práticas de desenvolvimento aplicadas na automação de testes com Selenium (Robson Bittencourt) • 20h45 às 21h15 Hands on com Selenium
- 3. Sobre o GUTS-RS • GUTS-RS: Grupo de Usuários de Testes de Software do RS • Criado em: agosto/2008 • Objetivo: compartilhar o uso de métodos, processos e ferramentas de Teste de Software e promover discussões sobre a aplicação das melhores práticas de teste e qualidade utilizadas no mercado • Público Alvo: Gerentes, Analistas de Testes, Testadores, Desenvolvedores e demais profissionais e estudantes interessados na área • Coordenação: Diraci Júnior, Eduardo Oliveira e Moisés Ramírez
- 4. Canais de Comunicação http://guts-rs.blogspot.com.br/ @gutsrs guts-rs-sucesu@googlegroups.com Grupo de Usuários de Testes de Software do RS Guts RS GUTS-RS http://pt.slideshare.net/GUTS-RS http://guts-rs.eventbrite.com/
- 5. Comunicados • Submissão de Palestras 2016 – DOJO – Fishbowl – Palestra – TCC – Testing Games – Workshop – Outros • Assinar a lista de presença • Preencher a Ficha do Evento • Certificado de Participação
- 6. Próximos Eventos • GUTS Talks (julho) Ferramentas de Automação de Testes
- 7. Sobre o palestrante Robson é graduado em Sistemas de Informação, pela Facensa de Gravataí. Busca estar sempre a par das boas práticas de construção de software, como testes, Clean Code e Design Patterns. Gosta de estudar coisas novas, principalmente assuntos relacionados a Engenharia de Software e Métodos Ágeis. Gosta de repassar as coisas que aprende e tem feito isso através de palestras e do seu blog.
- 9. Práticas de desenvolvimento aplicadas na automação de testes com Selenium
- 10. Agenda - Importância dos testes automatizados - Linguagens Orientadas a Objetos - Abstrações - SOLID - DRY - Design Patterns - Clean Code - Organização - Indo além
- 11. Importância dos testes automatizados
- 12. Feedback contínuo Importância dos testes automatizados
- 13. Nos dão segurança Importância dos testes automatizados
- 14. Liberam tempo para testes e tarefas mais complexas Importância dos testes automatizados
- 15. Uma vez escritos se tornam guardiões Importância dos testes automatizados
- 16. Importância dos testes automatizados
- 17. Importância dos testes automatizados
- 18. Mas porquê? Importância dos testes automatizados
- 19. Escrever testes funcionais é complexo Importância dos testes automatizados
- 20. http://www.toolsqa.com/java/junit-framework/junit-test-selenium-webdriver/ Importância dos testes automatizados
- 21. Linguagens Orientadas a Objetos
- 22. Linguagens Orientadas a Objetos Diferença entre o paradigma procedural e a orientação a objetos
- 24. Abstrações Carro
- 26. Abstrações Criar uma caixa de ferramentas
- 29. SOLID
- 30. SOLID S - Single responsability O - Open / closed L - Liskov substitution I - Interface segregation D - Dependency inversion
- 32. SOLID Open / Closed principle
- 33. SOLID Open / Closed principle
- 34. SOLID Open / Closed principle
- 35. SOLID Open / Closed principle
- 36. SOLID Open / Closed principle
- 37. DRY Don’t repeat yourself Não se repita
- 38. DRY
- 39. DRY
- 40. Design Patterns
- 41. Design Patterns - Solução reproduzível de um problema - Problemas clássicos geralmente possuem patterns - Não trazem a solução final - Instigam as boas práticas e princípios da orientação a objetos
- 42. Design Patterns Page Object Representa uma página Reusáveis Redução da manutenção Linguagem de domínio
- 45. Design Patterns Representam um elemento ou componente Encapsulam código do WebDriver Abstrações de elementos
- 46. Design Patterns Abstrações de elementos
- 47. Design Patterns Abstrações de elementos
- 48. Design Patterns Abstrações de elementos
- 49. Design Patterns Abstrações de elementos
- 50. Design Patterns Abstrações de elementos
- 51. Design Patterns Auxiliam na criação do setup de teste Reusáveis Foco no caso de teste Fixtures / Builders
- 52. Design Patterns Fixtures / Builders
- 53. Design Patterns Fixtures / Builders
- 54. Design Patterns Fixtures / Builders
- 55. Design Patterns Fixtures / Builders
- 56. Clean Code
- 57. Clean Code Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler, 2008.
- 62. Organização
- 64. Organização A classe de Teste deve criar seus próprios dados Testes independentes
- 65. Organização Uma classe de teste por funcionalidade testada Testes independentes
- 66. Organização Dependências dentro da mesma classe são aceitáveis Testes independentes
- 69. Indo Além
- 70. Indo Além Livros
- 71. Indo Além Livros
- 72. Indo Além Livros
- 74. ABSTRAÇÕES
Notas do Editor
- Explicar um pouco sobre a importância dos testes automatizados na qualidade do software
- Mostrar que podemos ter feedback contínuo ao executar os testes constantemente em um jenkins por exemplo
- Nos dão segurança na hora de realizar os deploys.
- Explicar que a suíte de testes automatizados libera tempo para o time de QA fazer tarefas mais importantes
- Falar sobre o valor dos testes, já que uma vez escritos eles ficam lá “para sempre”
- Mostrar a pirâmide de testes ideal
- E mostrar o que geralmente ocorre na realidade
- Questionar o porque isso ocorre
- Mostrar alguns exemplo de como escrever testes funcionais pode ser complexo
- Falar sobre o código complexo
- Explicar o que são as linguagens orientadas a objeto e como elas podem ajudar a simplificar os testes
- Explicar a diferença entre linguagens procedurais e orientadas a objeto. Enquanto a linguagem procedural trabalha com operações em uma sequencia. As linguagens orientadas a objeto criam abstrações que tem por objetivo trazer o modelo do mundo real para o código
- Começar a explicar o que são abstrações
- Explicar o quão abstrato é um carro. Por exemplo sabemos que ao apertar o acelerador o carro anda. Mas não sabemos ao certo como isso ocorre.
- Não vou usar as mesmas palavras, mas segue abaixo a metáfora: No Alasca, um esporte tradicional é cortar árvores. Há lenhadores famosos, com domínio, habilidade e energia no uso do machado. Querendo tornar-se também um grande lenhador, um jovem escutou falar do melhor de todos os lenhadores do país. Resolveu procurá-lo. - Quero ser seu discípulo. Quero aprender a cortar árvore como o senhor. O jovem empenhou-se no aprendizado das lições do mestre, e depois de algum tempo achou-se melhor que ele. Mais forte, mais ágil, mais jovem, venceria facilmente o velho lenhador. Desafiou o mestre para uma competição de oito horas, para ver qual dos dois cortaria mais árvores. O desafio foi aceito, e o jovem lenhador começou a cortar árvores com entusiasmo e vigor. Entre uma árvore e outra, olhava para o mestre, mas na maior parte das vezes o via sentado. O jovem voltava às suas árvores, certo da vitória, sentindo piedade pelo velho mestre. Quando terminou o dia, para grande surpresa do jovem, o velho mestre havia cortado muito mais árvores do que o seu desafiante. - Mas como é que pode? – surpreendeu-se. Quase todas as vezes em que olhei, você estava descansando! - Não, meu filho, eu não estava descansando. Estava afiando o machado. Foi por isso que você perdeu. Aprendizado é um processo que não tem fim. Sempre temos algo a aprender. O tempo utilizado para afiar o machado é recompensado valiosamente. O reforço no aprendizado, que dura a vida toda, é como afiar sempre o machado. Continue afiando o seu.
- Devemos afiar nosso machado Dedicar o tempo necessário para criar uma base para os testes, ou seja uma caixa de ferramenta. Isso irá fazer com que no futuro seja muito mais fácil escrever os testes.
- Para isso devemos ter muita atenção ao projeto de classes. O projeto de classes é como iremos organizar os objetos do nosso projeto de testes. Como eles irão interagir? Quais são os pontos principais? Quais são os pontos que tendem a mudar com o tempo?
- Pensar no projeto de classes é como um quebra cabeça Nesse quebra cabeça é muito mais importante a forma da peça, ou seja como nossas classes se relacionam com outras. Se temos que alterar a forma de uma peça, essa mudança irá se propagar para outras peças. Da mesma maneira no código. Portanto devemos sempre planejar muito bem como nossas classes irão interagir. O desenho da peça, ou seja a implentação do código, como ele faz o que faz, não é tão importante. Refatorar um algoritmo mal feito é fácil desde que a estrutura esteja bem feita, assim como seria fácil alterar a cor de uma peça em nosso quebra cabeça.
- SOLID é um acrônimo de cinco princípios de software, identificados por Robert C Martin (Uncle Bob). Esses princípios servem como guia para a escrita de códigos com boa manutenabilidade.
- Citar os 5 princípios Só vou explicar os 2 primeiros
- Classes devem ter somente uma responsabilidade. Isso implica que elas devem possuir somente um motivo para mudar. Dizemos que classes assim são classes coesas. Coesão Classes coesas tendem a ser menores e mais simples, menos suscetíveis a problemas, reúso mais fácil e a chance de propagarem problemas para outras classes é menor.
- O princípio do aberto/fechado diz que devemos manter nossas classes abertas para extensão e fechadas para alteração. Devemos identificar pontos do código que tendem a crescer com o tempo e extrair abstrações destes. Para que seja possível evoluir o código sem alterar o existente.
- Explicar o exemplo
- Explicar o exemplo
- Explicar o exemplo
- Explicar o exemplo
- Temos que ter cuidado quando escrevemos código duplicado. Se você se pega usando ctrl+c + ctrl+v, pare e pense duas vezes. Será que não é possível extrair um método que faz o que o código repetido fazia?
- Explicar o exemplo
- Explicar o exemplo
- Explicar o que é código limpo. Uma série de práticas que visam fazer com que o código escrito seja facilmente entendido por outras pessoas.
- Bons nomes nos ajudam a entender de forma mais fácil o código escrito. Porém as vezes dar bons nomes é difícil.
- Devemos sempre tentar escrever métodos pequenos. Métodos muito grandes são difíceis de dar manutenção. Geralmente não respeitam o princípio da responsabilidade única. Não existe um tamanho máximo correto, mas acredito que um método com mais que 15 linhas já deva levantar um alerta.
- Aqui vai ser polêmico. Comentários poluem o código. Além disso tendem a ser mentirosos, já que com o tempo o código irá sofrer mudanças e nem sempre as pessoas irão alterar os comentários para corresponder a nova realidade. Geralmente as duas práticas anteriores eliminam a necessidade dos comentários. Métodos pequenos são auto explicativos, e muitas vezes podemos substituir um comentário com um nome melhor para o método ou variável. Existem exceções. Documentações de api, TODO, e comentários em rotinas muito complicadas, podem ser uma exceção.
- Falar um pouco sobre organização do código
- Explicar a ideia de criar um fluxo de páginas. Os métodos sempre retornam a página seguinte. Assim ao ler o código fica claro o que espera-se que aconteça no browser.
- Quebrar os testes em blocos de given when e then 1º bloco criação dos dados necessários no testes 2º bloco método/cenário sobre teste 3º asserções
- Falar que todo mundo deve estar cheio de dúvidas e que vou mostrar mais algumas coisas para tentar ajudar nisso
- Livro da Casa do Código escrito pelo Mauricio Aniche. Livro muito bom, que da uma nova perspectiva sobre a orientação a objetos.
- Dois livros muito boons sobre Design Patterns O primeiro é mais para quem está começando e o segundo já é um pouco mais avançado
- Se eu pudesse recomendar somente um livro, recomendaria esse Esse livro ensina uma série de práticas que irá fazer com que você escreva um ótimo código
- Vou mostrar um projeto pessoal, que utiliza várias práticas faladas anteriormente. Vou fazer um livecoding nesse slide
- Reforçar a importância das abstrações