[GUTS-RS] Práticas de desenvolvimento aplicadas na automação de testes com Selenium

Notas do Editor

• #12: Explicar um pouco sobre a importância dos testes automatizados na qualidade do software
• #13: Mostrar que podemos ter feedback contínuo ao executar os testes constantemente em um jenkins por exemplo
• #14: Nos dão segurança na hora de realizar os deploys.
• #15: Explicar que a suíte de testes automatizados libera tempo para o time de QA fazer tarefas mais importantes
• #16: Falar sobre o valor dos testes, já que uma vez escritos eles ficam lá “para sempre”
• #17: Mostrar a pirâmide de testes ideal
• #18: E mostrar o que geralmente ocorre na realidade
• #19: Questionar o porque isso ocorre
• #20: Mostrar alguns exemplo de como escrever testes funcionais pode ser complexo
• #21: Falar sobre o código complexo
• #22: Explicar o que são as linguagens orientadas a objeto e como elas podem ajudar a simplificar os testes
• #23: 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
• #24: Começar a explicar o que são abstrações
• #25: 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.
• #26: 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. 
• #27: 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.
• #28: 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?
• #29: 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.
• #30: 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.
• #31: Citar os 5 princípios Só vou explicar os 2 primeiros
• #32: 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.
• #33: 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.
• #34: Explicar o exemplo
• #35: Explicar o exemplo
• #36: Explicar o exemplo
• #37: Explicar o exemplo
• #38: 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?
• #39: Explicar o exemplo
• #40: Explicar o exemplo
• #57: 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.
• #59: Bons nomes nos ajudam a entender de forma mais fácil o código escrito. Porém as vezes dar bons nomes é difícil.
• #61: 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.
• #62: 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.
• #63: Falar um pouco sobre organização do código
• #64: 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.
• #68: 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
• #70: Falar que todo mundo deve estar cheio de dúvidas e que vou mostrar mais algumas coisas para tentar ajudar nisso
• #71: Livro da Casa do Código escrito pelo Mauricio Aniche. Livro muito bom, que da uma nova perspectiva sobre a orientação a objetos.
• #72: Dois livros muito boons sobre Design Patterns O primeiro é mais para quem está começando e o segundo já é um pouco mais avançado
• #73: 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
• #74: Vou mostrar um projeto pessoal, que utiliza várias práticas faladas anteriormente. Vou fazer um livecoding nesse slide
• #75: Reforçar a importância das abstrações