PowerPoint Presentation
#gutsrs /@gutsrsPrticas de desenvolvimento aplicadas na automao de testes com Selenium
Robson Bittencourt
Programao19h15 s 19h45 Recepo, boas vindas e Coffee para integrao
19h45 s 19h55 Abertura do evento, apresentao do GUTS-RS e expectativas do evento
19h55 s 20h45 Prticas de desenvolvimento aplicadas na automao de testes com Selenium (Robson Bittencourt)
20h45 s 21h15 Hands on com Selenium
Sobre o GUTS-RSGUTS-RS: Grupo de Usurios de Testes de Software do RS
Criado em: agosto/2008
Objetivo: compartilhar o uso de mtodos, processos e ferramentas de Teste de Software e promover discusses sobre a aplicao das melhores prticas de teste e qualidade utilizadas no mercado
Pblico Alvo: Gerentes, Analistas de Testes, Testadores, Desenvolvedores e demais profissionais e estudantes interessados na rea
Coordenao: Diraci Jnior, Eduardo Oliveira e Moiss Ramrez
Canais de Comunicao
http://guts-rs.blogspot.com.br/
@gutsrs
Grupo de Usurios de Testes de Software do RSGuts RSGUTS-RS
http://pt.slideshare.net/GUTS-RS
http://guts-rs.eventbrite.com/
ComunicadosSubmisso de Palestras 2016DOJOFishbowlPalestraTCCTesting GamesWorkshopOutros
Assinar a lista de presena
Preencher a Ficha do Evento
Certificado de Participao
5
Prximos EventosGUTS Talks (julho)
Ferramentas de Automao de Testes
Sobre o palestranteRobson graduado em Sistemas de Informao, pela Facensa de Gravata. Busca estar sempre a par das boas prticas de construo de software, como testes, Clean Code e Design Patterns. Gosta de estudar coisas novas, principalmente assuntos relacionados a Engenharia de Software e Mtodos geis. Gosta de repassar as coisas que aprende e tem feito isso atravs de palestras e do seu blog.
Contatos
@rluizv
github.com/robsonbittencourt
rbittencourt.com
Prticas de desenvolvimento aplicadas na automao de testes com Selenium
9
Agenda- Importncia dos testes automatizados- Linguagens Orientadas a Objetos- Abstraes- SOLID- DRY- Design Patterns- Clean Code- Organizao- Indo alm
Importncia dos testes automatizados
Explicar um pouco sobre a importncia dos testes automatizados na qualidade do software11
Feedback contnuo
Importncia dos testes automatizados
Mostrar que podemos ter feedback contnuo ao executar os testes constantemente em um jenkins por exemplo12
Nos do segurana
Importncia dos testes automatizados
Nos do segurana na hora de realizar os deploys. 13
Liberam tempo para testes e tarefas mais complexas
Importncia dos testes automatizados
Explicar que a sute de testes automatizados libera tempo para o time de QA fazer tarefas mais importantes14
Uma vez escritos se tornam guardies
Importncia dos testes automatizados
Falar sobre o valor dos testes, j que uma vez escritos eles ficam l para sempre15
Importncia dos testes automatizados
Mostrar a pirmide de testes ideal16
Importncia dos testes automatizados
E mostrar o que geralmente ocorre na realidade17
Mas porqu?
Importncia dos testes automatizados
Questionar o porque isso ocorre18
Escrever testes funcionais complexo
Importncia dos testes automatizados
Mostrar alguns exemplo de como escrever testes funcionais pode ser complexo19
http://www.toolsqa.com/java/junit-framework/junit-test-selenium-webdriver/
Importncia dos testes automatizados
Falar sobre o cdigo complexo20
Linguagens Orientadas a Objetos
Explicar o que so as linguagens orientadas a objeto e como elas podem ajudar a simplificar os testes21
Linguagens Orientadas a ObjetosDiferena entre o paradigma procedural e a orientao a objetos
Explicar a diferena entre linguagens procedurais e orientadas a objeto.Enquanto a linguagem procedural trabalha com operaes em uma sequencia.As linguagens orientadas a objeto criam abstraes que tem por objetivo trazer o modelo do mundo real para o cdigo
22
AbstraesABSTRAES
Comear a explicar o que so abstraes
23
AbstraesCarro
Explicar o quo abstrato um carro.
Por exemplo sabemos que ao apertar o acelerador o carro anda. Mas no sabemos ao certo como isso ocorre.24
AbstraesMetfora do lenhador
No vou usar as mesmas palavras, mas segue abaixo a metfora:
No Alasca, um esporte tradicional cortar rvores. H lenhadores famosos, com domnio, habilidade e energia no uso do machado. Querendo tornar-se tambm um grande lenhador, um jovem escutou falar do melhor de todos os lenhadores do pas. Resolveu procur-lo.- Quero ser seu discpulo. Quero aprender a cortar rvore como o senhor.O jovem empenhou-se no aprendizado das lies 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 competio de oito horas, para ver qual dos dois cortaria mais rvores.O desafio foi aceito, e o jovem lenhador comeou 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 vitria, 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!- No, meu filho, eu no estava descansando. Estava afiando o machado. Foi por isso que voc perdeu.Aprendizado um processo que no tem fim. Sempre temos algo a aprender. O tempo utilizado para afiar o machado recompensado valiosamente. O reforo no aprendizado, que dura a vida toda, como afiar sempre o machado. Continue afiando o seu.
25
AbstraesCriar uma caixa de ferramentas
Devemos afiar nosso machadoDedicar o tempo necessrio para criar uma base para os testes, ou seja uma caixa de ferramenta.Isso ir fazer com que no futuro seja muito mais fcil escrever os testes.26
AbstraesProjeto de classes
Para isso devemos ter muita ateno ao projeto de classes.
O projeto de classes como iremos organizar os objetos do nosso projeto de testes.
Como eles iro interagir? Quais so os pontos principais? Quais so os pontos que tendem a mudar com o tempo?27
AbstraesQuebra-cabeas
Pensar no projeto de classes como um quebra cabea
Nesse quebra cabea muito mais importante a forma da pea, ou seja como nossas classes se relacionam com outras.
Se temos que alterar a forma de uma pea, essa mudana ir se propagar para outras peas. Da mesma maneira no cdigo. Portanto devemos sempre planejar muito bem como nossas classes iro interagir.
O desenho da pea, ou seja a implentao do cdigo, como ele faz o que faz, no to importante. Refatorar um algoritmo mal feito fcil desde que a estrutura esteja bem feita, assim como seria fcil alterar a cor de uma pea em nosso quebra cabea.28
SOLID
SOLID um acrnimo de cinco princpios de software, identificados por Robert C Martin (Uncle Bob).
Esses princpios servem como guia para a escrita de cdigos com boa manutenabilidade.29
SOLID
S - Single responsabilityO - Open / closedL - Liskov substitutionI - Interface segregationD - Dependency inversion
Citar os 5 princpios
S vou explicar os 2 primeiros30
SOLIDSingle responsability
Classes devem ter somente uma responsabilidade. Isso implica que elas devem possuir somente um motivo para mudar. Dizemos que classes assim so classes coesas.
Coeso
Classes coesas tendem a ser menores e mais simples, menos suscetveis a problemas, reso mais fcil e a chance de propagarem problemas para outras classes menor.31
SOLIDOpen / Closed principle
O princpio do aberto/fechado diz que devemos manter nossas classes abertas para extenso e fechadas para alterao.
Devemos identificar pontos do cdigo que tendem a crescer com o tempo e extrair abstraes destes. Para que seja possvel evoluir o cdigo sem alterar o existente.32
SOLIDOpen / Closed principle
Explicar o exemplo33
SOLIDOpen / Closed principle
Explicar o exemplo
34
SOLIDOpen / Closed principle
Explicar o exemplo
35
SOLIDOpen / Closed principle
Explicar o exemplo
36
DRY
Dont repeat yourself
No se repita
Temos que ter cuidado quando escrevemos cdigo duplicado.
Se voc se pega usando ctrl+c + ctrl+v, pare e pense duas vezes. Ser que no possvel extrair um mtodo que faz o que o cdigo repetido fazia?37
DRY
Explicar o exemplo
38
DRY
Explicar o exemplo
39
Design Patterns
40
Design PatternsSoluo reproduzvel de um problema
Problemas clssicos geralmente possuem patterns
No trazem a soluo final
Instigam as boas prticas e princpios da orientao a objetos
41
Design PatternsPage ObjectRepresenta uma pgina
Reusveis
Reduo da manuteno
Linguagem de domnio
42
Design PatternsPage Object
Design PatternsPage Object
Design PatternsRepresentam um elemento ou componente
Encapsulam cdigo do WebDriver
Abstraes de elementos
Design PatternsAbstraes de elementos
Design PatternsAbstraes de elementos
Design PatternsAbstraes de elementos
Design PatternsAbstraes de elementos
49
Design PatternsAbstraes de elementos
50
Design PatternsAuxiliam na criao do setup de teste
Reusveis
Foco no caso de testeFixtures / Builders
Design PatternsFixtures / Builders
52
Design PatternsFixtures / Builders
53
Design PatternsFixtures / Builders
54
Design PatternsFixtures / Builders
55
Clean Code
Explicar o que cdigo limpo. Uma srie de prticas que visam fazer com que o cdigo escrito seja facilmente entendido por outras pessoas.56
Clean CodeAny fool can write code that a computer can understand. Good programmers write code that humans can understand.
Martin Fowler, 2008.
57
Clean CodeBons nomes
Bons nomes nos ajudam a entender de forma mais fcil o cdigo escrito.
Porm as vezes dar bons nomes difcil.58
Clean CodeBons nomes
59
Clean CodeMtodos Pequenos
Devemos sempre tentar escrever mtodos pequenos.
Mtodos muito grandes so difceis de dar manuteno. Geralmente no respeitam o princpio da responsabilidade nica.
No existe um tamanho mximo correto, mas acredito que um mtodo com mais que 15 linhas j deva levantar um alerta.60
Clean CodeComentrios
Aqui vai ser polmico.
Comentrios poluem o cdigo. Alm disso tendem a ser mentirosos, j que com o tempo o cdigo ir sofrer mudanas e nem sempre as pessoas iro alterar os comentrios para corresponder a nova realidade.
Geralmente as duas prticas anteriores eliminam a necessidade dos comentrios. Mtodos pequenos so auto explicativos, e muitas vezes podemos substituir um comentrio com um nome melhor para o mtodo ou varivel.
Existem excees. Documentaes de api, TODO, e comentrios em rotinas muito complicadas, podem ser uma exceo.61
Organizao
Falar um pouco sobre organizao do cdigo62
OrganizaoFluxo de Pginas
Explicar a ideia de criar um fluxo de pginas.
Os mtodos sempre retornam a pgina seguinte.
Assim ao ler o cdigo fica claro o que espera-se que acontea no browser.
63
Organizao
A classe de Teste deve criar seus prprios dados
Testes independentes
64
Organizao
Uma classe de teste por funcionalidade testada
Testes independentes
Organizao
Dependncias dentro da mesma classe so aceitveis
Testes independentes
Organizaogiven-when-then
Quebrar os testes em blocos de given when e then
1 bloco criao dos dados necessrios no testes2 bloco mtodo/cenrio sobre teste3 asseres67
68
Indo Alm
Falar que todo mundo deve estar cheio de dvidas e que vou mostrar mais algumas coisas para tentar ajudar nisso69
Indo AlmLivros
Livro da Casa do Cdigo escrito pelo Mauricio Aniche.
Livro muito bom, que da uma nova perspectiva sobre a orientao a objetos.70
Indo AlmLivros
Dois livros muito boons sobre Design Patterns
O primeiro mais para quem est comeando e o segundo j um pouco mais avanado71
Indo AlmLivros
Se eu pudesse recomendar somente um livro, recomendaria esse
Esse livro ensina uma srie de prticas que ir fazer com que voc escreva um timo cdigo72
Indo AlmMokona
github.com/robsonbittencourt/mokona
Vou mostrar um projeto pessoal, que utiliza vrias prticas faladas anteriormente.
Vou fazer um livecoding nesse slide73
ABSTRAES
Reforar a importncia das abstraes74
Dvidas?
75