[guts-rs] práticas de desenvolvimento aplicadas na automação de testes com selenium

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

[email protected]

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

[email protected]

@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


Mostrar que podemos ter feedback contnuo ao executar os testes constantemente em um jenkins por exemplo12

Nos do segurana


Nos do segurana na hora de realizar os deploys. 13

Liberam tempo para testes e tarefas mais complexas


Explicar que a sute de testes automatizados libera tempo para o time de QA fazer tarefas mais importantes14

Uma vez escritos se tornam guardies


Falar sobre o valor dos testes, j que uma vez escritos eles ficam l para sempre15


Mostrar a pirmide de testes ideal16


E mostrar o que geralmente ocorre na realidade17

Mas porqu?


Questionar o porque isso ocorre18

Escrever testes funcionais complexo


Mostrar alguns exemplo de como escrever testes funcionais pode ser complexo19

http://www.toolsqa.com/java/junit-framework/junit-test-selenium-webdriver/


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


Explicar o exemplo33


Explicar o exemplo

34


Explicar o exemplo

35


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




49


50

Design PatternsAuxiliam na criao do setup de teste

Reusveis

Foco no caso de testeFixtures / Builders

Design PatternsFixtures / Builders

52


53


54


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


Organizao

Dependncias dentro da mesma classe so aceitveis


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

[email protected]

Dvidas?

75

[guts-rs] práticas de desenvolvimento aplicadas na automação de testes com selenium

Technology