SlideShare uma empresa Scribd logo
Globalcode – Open4education
Clean Code para Testers
Stefan Teixeira
stefanfk@gmail.com / stefanteixeira.com.br
Sobre o palestrante
Stefan Teixeira
• QA Engineer @ M4U
• Bacharel em Ciência da Computação pela UFRJ
• MBA em Garantia de Qualidade de Software pela Escola Politécnica da UFRJ
• Mantém um blog técnico sobre testes: stefanteixeira.com.br
• Entusiasta de Testes Automatizados, Agile Testing e da cultura DevOps
Contatos:
• E-mail: stefanfk@gmail.com
• Twitter: twitter.com/stefan_teixeira
• Facebook: facebook.com/stefan.teixeira
• LinkedIn: linkedin.com/in/stefanteixeira
• GitHub: github.com/stefanteixeira
• SlideShare: slideshare.net/stefanteixeira
Clean Code
TDC 2015 São Paulo - Clean Code para Testers
Como me senti quando
comecei a ler o livro…
Mas depois…
Por que Clean Code?
TDC 2015 São Paulo - Clean Code para Testers
O custo de código ruim
O que é Clean Code?
“I like my code to be elegant and
efficient. Clean code does one thing
well.”
Bjarne Stroustrup, criador do C++
“Clean code always looks like it was
written by someone who cares.”
Michael Feathers, criador do livro “Working
Effectively with Legacy Code"
“You know you are working on clean code
when each routine you read turns out to
be pretty much what you expected”
Ward Cunningham, criador do Wiki, do Fit e um dos
signatários originais do Manifesto Ágil
The Boy Scout Rule
“Leave the campground cleaner than you
found it."
6 pontos sobre Clean
Code importantes para um
tester
#1: Nomes Significativos
Use nomes que revelem a
intenção!
“Se um nome requer um comentário, então ele não
revela sua intenção."
int v1; //valor do produto à vista
int v2; //valor total do produto a prazo
int v3 = v2 - v1; //diferença entre valores à vista e a prazo
int valorAVista;
int valorAPrazo;
int diferencaEntreValoresAVistaAPrazo;
Use nomes buscáveis!
• Evite usar variáveis com apenas uma letra
‣ Usar apenas como variáveis de controle (em um
“for”, por exemplo)
• Evite usar valores “hardcoded" (constantes, strings,
etc.)
assertEquals(“Cadastrado com sucesso”, cadastroPage.getMensagem());
public static final String MSG_SUCESSO = “Cadastrado com sucesso”;
assertEquals( MSG_SUCESSO, cadastroPage.getMessage() );
Nomes de classes e métodos
Classes:
• Devem conter substantivos ou frases nominais
• Ex: LoginPage, Usuario, ConnectionFactory, Conta…
Métodos:
• Devem conter verbos ou frases verbais
• Ex: deletarPagina, salvar, incluirUsuario,
removerConta
#2: Classes
Não crie classes Megazord!
Classes devem ser pequenas!
“The first rule of classes is that they should be small.
The second rule is that they should be smaller than
that.”
“Se a gente não consegue dar um nome sucinto a
uma classe, então provavelmente a classe é grande
demais.”
SRP (Single Responsibility
Principle)
“Uma classe ou módulo deve ter um, e
apenas um, motivo para mudar."
#3: Funções
Cuidado com os Zords…
Funções devem ser pequenas!
“The first rule of functions is that they
should be small. The second rule is that
they should be smaller than that.”
Use nomes descritivos!
“Não tenha medo de dar um nome longo a uma função.
Um nome longo e descritivo é melhor do que um curto
e enigmático.
Um nome longo e descritivo é melhor do que um
comentário.”
//Testa a inclusão de um usuário informando CPF inválido
testeIncluirFalha()
testeIncluirUsuarioComCPFInvalidoSemSucesso()
Faça apenas uma coisa!
public static String renderizarPaginaComSetupsETeardowns(PageData
pageData, boolean isSuite) throws Exception {
if( isTestPage(pageData) )
{
incluiSetupsETeardowns(pageData, isSuite);
}
return pageData.getHtml();
}
O método faz apenas uma coisa?
1) Determina se a página é uma página de teste
2) Caso seja, inclui setups e teardowns
3) Renderiza a página em HTML
Faça apenas uma coisa!
• Parágrafo PARA:
PARA renderizarPaginaComSetupsETeardowns, verificamos se
a página é uma página de teste e, caso seja, incluímos os
setups e teardowns. Em ambos os casos, renderizamos a
página em HTML.
Observe que todos os passos da função do
exemplo estão a um nível de abstração abaixo
do seu nome.
E esse método?
public static String renderizarPaginaComSetupsETeardowns(PageData
pageData, boolean isSuite) throws Exception {
if( isTestPage(pageData) )
{
WikiPage testPage = pageData.getWikiPage();
StringBuffer newPageContent = new StringBuffer();
includeSetupPages(testPage, newPageContent, isSuite);
newPageContent.append(pageData.getContent());
includeTeardownPages(testPage, newPageContent, isSuite);
pageData.setContent(newPageContent.toString());
}
return pageData.getHtml();
}
Como ficaria o parágrafo PARA nesse caso?
Como saber se a função faz apenas uma
coisa?
• Veja se é possível extrair outra função com um nome que
não seja uma reafirmação da implementação inicial.
“Se uma função executa passos que estão a apenas
um nível de abstração abaixo do seu nome, então a
função faz apenas uma coisa.”
“Funções que fazem apenas uma coisa não podem
ser divididas em seções."
DRY (Don’t Repeat Yourself)
LoginPage.java
public HomePage login(String _usuario, String _senha) {
usuario.sendKeys(_usuario);
senha.sendKeys(_senha);
loginForm.submit();
return new HomePage(driver);
}
public LoginPage loginSemSucesso(String _usuario, String_senha) {
usuario.sendKeys(_usuario);
senha.sendKeys(_senha);
loginForm.submit();
wait.until(ExpectedConditions.visibilityOf( mensagemErro ));
return this;
}
DRY (Don’t Repeat Yourself)
LoginPage.java
public HomePage login(String _usuario, String _senha) {
preencherESubmeterForm(_usuario, _senha);
return new HomePage(driver);
}
public LoginPage loginSemSucesso(String _usuario, String _senha) {
preencherESubmeterForm(_usuario, _senha);
wait.until(ExpectedConditions.visibilityOf( mensagemErro ));
return this;
}
private void preencherESubmeterForm(String _usuario, String _senha) {
usuario.sendKeys(_usuario);
senha.sendKeys(_senha);
loginForm.submit();
}
#4: Comentários
“Don’t comment bad code - rewrite it.”
“The proper use of comments is to compensate for our
failure to express ourself in code.”
“Innacurate comments are far worse than no comments
at all. Truth can only be found in one place: the code.”
Comentários BONS
• Comentários legais (copyright)
• TODOs
‣ Cuidado para não encher o código com TODOs
• Amplificar importância
‣ Dar ênfase em algo importante que possa
passar despercebido
Comentários BONS
• Aviso sobre consequências
Comentários RUINS
• Redundância
//Método usado para preencher o form de login, passando usuário e senha
como parâmetros e submetendo o form em seguida
private void preencherESubmeterForm(String _usuario, String _senha) {
usuario.sendKeys(_usuario);
senha.sendKeys(_senha);
loginForm.submit();
}
Comentários RUINS
• Comentários obrigatórios
/**
* @param _usuario Nome do usuario
* @param _senha Senha do usuario
*/
public void preencherESubmeterForm(String _usuario, String _senha) {
usuario.sendKeys(_usuario);
senha.sendKeys(_senha);
loginForm.submit();
}
Comentários RUINS
• Noise comments (reafirmam o óbvio)
/**
* Retorna o nome
* @return o nome
*/
public String getNome() {
return nome;
}
Comentários RUINS
• Código comentado
‣ Quem encontrar um trecho de código
comentado não vai ter coragem de deletá-
lo. Podem pensar que é algo importante.
‣ Pratique o desapego. Temos ferramentas
de controle de versão para isso. :)
Comentários RUINS
• Comentários em HTML
Comentários RUINS
• Comentários extensos
#5: Formatação
• Funções Dependentes
‣ Se uma função chama outra, elas devem estar
próximas verticalmente, e a função que chama deve
estar acima da que é chamada, se possível.
‣ Isso dá a seu código um fluxo natural.
• Afinidade Conceitual
‣Quanto maior for a afinidade entre conceitos de
funções, menor deve ser a distância vertical entre
elas.
• Formatação Vertical
‣ Projetos Java complexos (JUnit, TestNG, Ant,
Tomcat) não possuem arquivos com mais de 500
linhas
• Formatação Horizontal
‣Cuidado com scroll horizontal!
• Indentação
‣ "Without indentation, programs would be virtually
unreadable by humans”
#6: Testes
Era uma vez uma
equipe…
… que não se importava com a
qualidade do código de testes.
Com o passar das releases, o
custo de manter a suite só
aumentava…
… até que tiveram que descartar a
suite inteira.
Moral da História
Código de teste é tão
importante quanto código
de produção!
“Having dirty tests is equivalent to, if not
worse than, having no tests.”
“What makes a clean test? Three things.
Readability, readability, and readability.”
Mantenha seus testes limpos!
Conclusão
“Any fool can write code that a computer
can understand. Good programmers write
code that humans can understand.”
- Martin Fowler
“Refactoring is an iterative process full of
trial and error, inevitably converging on
something we feel is worthy of a
professional."
- "Uncle Bob" Martin
Outros livros recomendados
Globalcode – Open4education
Obrigado!
Stefan Teixeira
stefanfk@gmail.com
stefanteixeira.com.br
@stefan_teixeira

Mais conteúdo relacionado

PDF
VR Dev Summit 2016 - Primeiros Passos em Automação de Testes
PDF
1º Encontro do Grupo de Testes Carioca - Primeiros Passos em Automação de Testes
PDF
TDC 2016 Floripa - Criando APIs REST em minutos com Spark + Java 8
PDF
TDC 2015 São Paulo - Testes Automatizados de todos os tipos utilizando biblio...
PDF
Scrum Gathering Rio 2015 - Testando na nuvem a UI e o JavaScript de sua aplic...
PDF
Agile Brazil 2016 - 5 fundamentos essenciais de padrões xUnit
PDF
Meetup DevOps Carioca - Testes de Carga com Locust
PDF
Minas Testing Conference 2016 - Testes de Carga com Locust
VR Dev Summit 2016 - Primeiros Passos em Automação de Testes
1º Encontro do Grupo de Testes Carioca - Primeiros Passos em Automação de Testes
TDC 2016 Floripa - Criando APIs REST em minutos com Spark + Java 8
TDC 2015 São Paulo - Testes Automatizados de todos os tipos utilizando biblio...
Scrum Gathering Rio 2015 - Testando na nuvem a UI e o JavaScript de sua aplic...
Agile Brazil 2016 - 5 fundamentos essenciais de padrões xUnit
Meetup DevOps Carioca - Testes de Carga com Locust
Minas Testing Conference 2016 - Testes de Carga com Locust

Mais procurados (17)

PDF
TDC 2016 SP - Desmistificando cobertura de código como métrica de qualidade
PPTX
Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...
PDF
TDC 2016 Floripa - Aprendendo Docker sem bruxaria
PDF
TDC 2016 SP - Cobertura de código de procedures T-SQL com SQLCC
PDF
Tester, pegue suas coisas, você está demitido
PDF
QConRio 2014 - Uso de Headless Browsers em Testes Automatizados
PDF
Semana da Computação UFRJ - Testes Automatizados: bruxaria ou não?
PDF
TDC 2014 SP - Visual Regression Testing com PhantomCSS
PDF
TDC 2015 Floripa - Visual Regression Testing em ambientes na nuvem
PDF
Agile Brazil 2014 - Visual Regression Testing com PhantomCSS
PDF
Testes de software
PDF
4º Encontro do Grupo de Testes Carioca - Testes de Carga com Locust
PPSX
DevQA - Da zona de conforto ao comprometimento com a Qualidade
PDF
In tests we trust: começando com TDD, mocks e mais
PDF
Mtc docker - utilizando no seu dia a dia
PDF
Minas Testing Conference 2015 - Visual Regression Testing em ambientes na nuvem
PDF
3 noções básicas para automação de testes efetivos - Taíse Dias da Silva
TDC 2016 SP - Desmistificando cobertura de código como métrica de qualidade
Samanta Cicilia - MTC - Importância de Testes Automatizados para Continuous D...
TDC 2016 Floripa - Aprendendo Docker sem bruxaria
TDC 2016 SP - Cobertura de código de procedures T-SQL com SQLCC
Tester, pegue suas coisas, você está demitido
QConRio 2014 - Uso de Headless Browsers em Testes Automatizados
Semana da Computação UFRJ - Testes Automatizados: bruxaria ou não?
TDC 2014 SP - Visual Regression Testing com PhantomCSS
TDC 2015 Floripa - Visual Regression Testing em ambientes na nuvem
Agile Brazil 2014 - Visual Regression Testing com PhantomCSS
Testes de software
4º Encontro do Grupo de Testes Carioca - Testes de Carga com Locust
DevQA - Da zona de conforto ao comprometimento com a Qualidade
In tests we trust: começando com TDD, mocks e mais
Mtc docker - utilizando no seu dia a dia
Minas Testing Conference 2015 - Visual Regression Testing em ambientes na nuvem
3 noções básicas para automação de testes efetivos - Taíse Dias da Silva
Anúncio

Destaque (17)

PDF
TDC 2014 POA - Clean Code para Testers
PPTX
TheDevConf 2015 Testes Kanban
PDF
Reactive microservices
PPT
TDC 2014 Floripa - Melhorando sua Estratégia de Testes Automatizados
PDF
Testes UI: não aceite mais falso negativos
PDF
Scrum Gathering Rio 2014 - Melhorando sua Estratégia de Testes Automatizados
PDF
TDC 2015 Floripa - Testes Automatizados de todos os tipos utilizando bibliote...
PPTX
Continuous Delivery & APIs - Evoluindo uma Arquitetura Orientada a Serviços
PDF
TDC 2016 SP - Continuous Delivery para aplicações Java com ferramentas open-s...
PDF
Palestra sobre Automação de Testes com Rest-Assured
PDF
Testes em uma startup do mundo financeiro
PDF
Scrum Gathering Portugal 2016 - Containerizing Tests with Docker
PDF
TDC2016SP - Trilha Microservices
PPT
TDC2016SP - Trilha Microservices
PDF
TDC2016SP - Trilha Microservices
PDF
TDC2016SP - Trilha Microservices
PDF
TDC 2016 SP - 5 libs de teste JavaScript que você deveria conhecer
TDC 2014 POA - Clean Code para Testers
TheDevConf 2015 Testes Kanban
Reactive microservices
TDC 2014 Floripa - Melhorando sua Estratégia de Testes Automatizados
Testes UI: não aceite mais falso negativos
Scrum Gathering Rio 2014 - Melhorando sua Estratégia de Testes Automatizados
TDC 2015 Floripa - Testes Automatizados de todos os tipos utilizando bibliote...
Continuous Delivery & APIs - Evoluindo uma Arquitetura Orientada a Serviços
TDC 2016 SP - Continuous Delivery para aplicações Java com ferramentas open-s...
Palestra sobre Automação de Testes com Rest-Assured
Testes em uma startup do mundo financeiro
Scrum Gathering Portugal 2016 - Containerizing Tests with Docker
TDC2016SP - Trilha Microservices
TDC2016SP - Trilha Microservices
TDC2016SP - Trilha Microservices
TDC2016SP - Trilha Microservices
TDC 2016 SP - 5 libs de teste JavaScript que você deveria conhecer
Anúncio

Semelhante a TDC 2015 São Paulo - Clean Code para Testers (20)

PDF
Livro - código limpo caps (3,4) (clean code)
PDF
Boas práticas no desenvolvimento de software
PPTX
PDF
Refatoração - aquela caprichada no código
PDF
Removendo o cheiro ruim do seu código - PHPSC Conf 2011
KEY
Django - Desenvolvimento web ágil com Python
PDF
11-codigo-limpo-parte-4.pdf
PPTX
JAVA - Tipos de dados. - Operadores e prioridades; - Tipo variáveis; Definiçã...
PDF
Java - Introdução a banco de dados
PPTX
Refatoração
PDF
Tutorial visão automação de testes e casper js
PPTX
Tutorial - Visão sobre Automação de Testes com CasperJS
PPT
Aula JPA
PPTX
Qualidade de Código
PDF
Spring framework 2.5
PPT
Desenvolvimento Agil Com Doctrine Orm
PPTX
Código limpo
PDF
Teste de Integração - Unidade III
PDF
Código limpo: Funções Capítulo 3
PPT
Refactory Worshop
Livro - código limpo caps (3,4) (clean code)
Boas práticas no desenvolvimento de software
Refatoração - aquela caprichada no código
Removendo o cheiro ruim do seu código - PHPSC Conf 2011
Django - Desenvolvimento web ágil com Python
11-codigo-limpo-parte-4.pdf
JAVA - Tipos de dados. - Operadores e prioridades; - Tipo variáveis; Definiçã...
Java - Introdução a banco de dados
Refatoração
Tutorial visão automação de testes e casper js
Tutorial - Visão sobre Automação de Testes com CasperJS
Aula JPA
Qualidade de Código
Spring framework 2.5
Desenvolvimento Agil Com Doctrine Orm
Código limpo
Teste de Integração - Unidade III
Código limpo: Funções Capítulo 3
Refactory Worshop

Mais de Stefan Teixeira (12)

PDF
Latinoware 2016 - Continuous Delivery com ferramentas open source
PDF
Ágiles 2016 - Using open source tools to support Continuous Delivery
PDF
6º Encontro do Grupo de Testes Carioca - Testes em um contexto de Continuous ...
PDF
Scrum Gathering Rio 2016 - Conteinerizando Testes com Docker Compose
PDF
TDC 2016 Floripa - Testando APIs REST com Supertest e Promises
PDF
Agile Testers Conference 2016 - GoCD + Docker + Docker Compose: uma história ...
PDF
Meetup DevOps Carioca - GoCD + Docker + Docker Compose: uma história de amor
PDF
Meetup AngularJS Rio - Testes e2e para apps AngularJS com Protractor
PDF
Testadores 2015 - O Fantástico Mundo de Docker
PDF
Agile Brazil 2015 - Testando na Nuvem a UI e o JavaScript de sua aplicação
PDF
TDC 2015 POA - O Fantástico Mundo de Docker
PDF
Mobile Conf 2015 - Testes de Unidade com Robolectric
Latinoware 2016 - Continuous Delivery com ferramentas open source
Ágiles 2016 - Using open source tools to support Continuous Delivery
6º Encontro do Grupo de Testes Carioca - Testes em um contexto de Continuous ...
Scrum Gathering Rio 2016 - Conteinerizando Testes com Docker Compose
TDC 2016 Floripa - Testando APIs REST com Supertest e Promises
Agile Testers Conference 2016 - GoCD + Docker + Docker Compose: uma história ...
Meetup DevOps Carioca - GoCD + Docker + Docker Compose: uma história de amor
Meetup AngularJS Rio - Testes e2e para apps AngularJS com Protractor
Testadores 2015 - O Fantástico Mundo de Docker
Agile Brazil 2015 - Testando na Nuvem a UI e o JavaScript de sua aplicação
TDC 2015 POA - O Fantástico Mundo de Docker
Mobile Conf 2015 - Testes de Unidade com Robolectric

Último (11)

PDF
Manejo integrado de pragas na cultura do algodão
PPTX
Arquitetura de computadores - Memórias Secundárias
PPTX
Viasol Energia Solar -Soluções para geração e economia de energia
PPTX
Utilizando code blockes por andre backes
PDF
Termos utilizados na designação de relação entre pessoa e uma obra.pdf
PPTX
Design - Introdução a Gestalt e teoria das formas
PPTX
Eng. Software - pontos essenciais para o início
PDF
eBook - GUIA DE CONSULTA RAPIDA EM ROTEADORES E SWITCHES CISCO - VOL I.pdf
PPTX
Informática Aplicada Informática Aplicada Plano de Ensino - estudo de caso NR...
PPTX
Proposta de Implementação de uma Rede de Computador Cabeada.pptx
PPTX
Tipos de servidor em redes de computador.pptx
Manejo integrado de pragas na cultura do algodão
Arquitetura de computadores - Memórias Secundárias
Viasol Energia Solar -Soluções para geração e economia de energia
Utilizando code blockes por andre backes
Termos utilizados na designação de relação entre pessoa e uma obra.pdf
Design - Introdução a Gestalt e teoria das formas
Eng. Software - pontos essenciais para o início
eBook - GUIA DE CONSULTA RAPIDA EM ROTEADORES E SWITCHES CISCO - VOL I.pdf
Informática Aplicada Informática Aplicada Plano de Ensino - estudo de caso NR...
Proposta de Implementação de uma Rede de Computador Cabeada.pptx
Tipos de servidor em redes de computador.pptx

TDC 2015 São Paulo - Clean Code para Testers

  • 1. Globalcode – Open4education Clean Code para Testers Stefan Teixeira [email protected] / stefanteixeira.com.br
  • 2. Sobre o palestrante Stefan Teixeira • QA Engineer @ M4U • Bacharel em Ciência da Computação pela UFRJ • MBA em Garantia de Qualidade de Software pela Escola Politécnica da UFRJ • Mantém um blog técnico sobre testes: stefanteixeira.com.br • Entusiasta de Testes Automatizados, Agile Testing e da cultura DevOps Contatos: • E-mail: [email protected] • Twitter: twitter.com/stefan_teixeira • Facebook: facebook.com/stefan.teixeira • LinkedIn: linkedin.com/in/stefanteixeira • GitHub: github.com/stefanteixeira • SlideShare: slideshare.net/stefanteixeira
  • 5. Como me senti quando comecei a ler o livro…
  • 9. O custo de código ruim
  • 10. O que é Clean Code?
  • 11. “I like my code to be elegant and efficient. Clean code does one thing well.” Bjarne Stroustrup, criador do C++
  • 12. “Clean code always looks like it was written by someone who cares.” Michael Feathers, criador do livro “Working Effectively with Legacy Code"
  • 13. “You know you are working on clean code when each routine you read turns out to be pretty much what you expected” Ward Cunningham, criador do Wiki, do Fit e um dos signatários originais do Manifesto Ágil
  • 14. The Boy Scout Rule “Leave the campground cleaner than you found it."
  • 15. 6 pontos sobre Clean Code importantes para um tester
  • 17. Use nomes que revelem a intenção! “Se um nome requer um comentário, então ele não revela sua intenção." int v1; //valor do produto à vista int v2; //valor total do produto a prazo int v3 = v2 - v1; //diferença entre valores à vista e a prazo int valorAVista; int valorAPrazo; int diferencaEntreValoresAVistaAPrazo;
  • 18. Use nomes buscáveis! • Evite usar variáveis com apenas uma letra ‣ Usar apenas como variáveis de controle (em um “for”, por exemplo) • Evite usar valores “hardcoded" (constantes, strings, etc.) assertEquals(“Cadastrado com sucesso”, cadastroPage.getMensagem()); public static final String MSG_SUCESSO = “Cadastrado com sucesso”; assertEquals( MSG_SUCESSO, cadastroPage.getMessage() );
  • 19. Nomes de classes e métodos Classes: • Devem conter substantivos ou frases nominais • Ex: LoginPage, Usuario, ConnectionFactory, Conta… Métodos: • Devem conter verbos ou frases verbais • Ex: deletarPagina, salvar, incluirUsuario, removerConta
  • 21. Não crie classes Megazord!
  • 22. Classes devem ser pequenas! “The first rule of classes is that they should be small. The second rule is that they should be smaller than that.” “Se a gente não consegue dar um nome sucinto a uma classe, então provavelmente a classe é grande demais.”
  • 23. SRP (Single Responsibility Principle) “Uma classe ou módulo deve ter um, e apenas um, motivo para mudar."
  • 25. Cuidado com os Zords…
  • 26. Funções devem ser pequenas! “The first rule of functions is that they should be small. The second rule is that they should be smaller than that.”
  • 27. Use nomes descritivos! “Não tenha medo de dar um nome longo a uma função. Um nome longo e descritivo é melhor do que um curto e enigmático. Um nome longo e descritivo é melhor do que um comentário.” //Testa a inclusão de um usuário informando CPF inválido testeIncluirFalha() testeIncluirUsuarioComCPFInvalidoSemSucesso()
  • 28. Faça apenas uma coisa! public static String renderizarPaginaComSetupsETeardowns(PageData pageData, boolean isSuite) throws Exception { if( isTestPage(pageData) ) { incluiSetupsETeardowns(pageData, isSuite); } return pageData.getHtml(); } O método faz apenas uma coisa? 1) Determina se a página é uma página de teste 2) Caso seja, inclui setups e teardowns 3) Renderiza a página em HTML
  • 29. Faça apenas uma coisa! • Parágrafo PARA: PARA renderizarPaginaComSetupsETeardowns, verificamos se a página é uma página de teste e, caso seja, incluímos os setups e teardowns. Em ambos os casos, renderizamos a página em HTML. Observe que todos os passos da função do exemplo estão a um nível de abstração abaixo do seu nome.
  • 30. E esse método? public static String renderizarPaginaComSetupsETeardowns(PageData pageData, boolean isSuite) throws Exception { if( isTestPage(pageData) ) { WikiPage testPage = pageData.getWikiPage(); StringBuffer newPageContent = new StringBuffer(); includeSetupPages(testPage, newPageContent, isSuite); newPageContent.append(pageData.getContent()); includeTeardownPages(testPage, newPageContent, isSuite); pageData.setContent(newPageContent.toString()); } return pageData.getHtml(); } Como ficaria o parágrafo PARA nesse caso?
  • 31. Como saber se a função faz apenas uma coisa? • Veja se é possível extrair outra função com um nome que não seja uma reafirmação da implementação inicial. “Se uma função executa passos que estão a apenas um nível de abstração abaixo do seu nome, então a função faz apenas uma coisa.” “Funções que fazem apenas uma coisa não podem ser divididas em seções."
  • 32. DRY (Don’t Repeat Yourself) LoginPage.java public HomePage login(String _usuario, String _senha) { usuario.sendKeys(_usuario); senha.sendKeys(_senha); loginForm.submit(); return new HomePage(driver); } public LoginPage loginSemSucesso(String _usuario, String_senha) { usuario.sendKeys(_usuario); senha.sendKeys(_senha); loginForm.submit(); wait.until(ExpectedConditions.visibilityOf( mensagemErro )); return this; }
  • 33. DRY (Don’t Repeat Yourself) LoginPage.java public HomePage login(String _usuario, String _senha) { preencherESubmeterForm(_usuario, _senha); return new HomePage(driver); } public LoginPage loginSemSucesso(String _usuario, String _senha) { preencherESubmeterForm(_usuario, _senha); wait.until(ExpectedConditions.visibilityOf( mensagemErro )); return this; } private void preencherESubmeterForm(String _usuario, String _senha) { usuario.sendKeys(_usuario); senha.sendKeys(_senha); loginForm.submit(); }
  • 35. “Don’t comment bad code - rewrite it.” “The proper use of comments is to compensate for our failure to express ourself in code.” “Innacurate comments are far worse than no comments at all. Truth can only be found in one place: the code.”
  • 36. Comentários BONS • Comentários legais (copyright) • TODOs ‣ Cuidado para não encher o código com TODOs • Amplificar importância ‣ Dar ênfase em algo importante que possa passar despercebido
  • 37. Comentários BONS • Aviso sobre consequências
  • 38. Comentários RUINS • Redundância //Método usado para preencher o form de login, passando usuário e senha como parâmetros e submetendo o form em seguida private void preencherESubmeterForm(String _usuario, String _senha) { usuario.sendKeys(_usuario); senha.sendKeys(_senha); loginForm.submit(); }
  • 39. Comentários RUINS • Comentários obrigatórios /** * @param _usuario Nome do usuario * @param _senha Senha do usuario */ public void preencherESubmeterForm(String _usuario, String _senha) { usuario.sendKeys(_usuario); senha.sendKeys(_senha); loginForm.submit(); }
  • 40. Comentários RUINS • Noise comments (reafirmam o óbvio) /** * Retorna o nome * @return o nome */ public String getNome() { return nome; }
  • 41. Comentários RUINS • Código comentado ‣ Quem encontrar um trecho de código comentado não vai ter coragem de deletá- lo. Podem pensar que é algo importante. ‣ Pratique o desapego. Temos ferramentas de controle de versão para isso. :)
  • 45. • Funções Dependentes ‣ Se uma função chama outra, elas devem estar próximas verticalmente, e a função que chama deve estar acima da que é chamada, se possível. ‣ Isso dá a seu código um fluxo natural. • Afinidade Conceitual ‣Quanto maior for a afinidade entre conceitos de funções, menor deve ser a distância vertical entre elas.
  • 46. • Formatação Vertical ‣ Projetos Java complexos (JUnit, TestNG, Ant, Tomcat) não possuem arquivos com mais de 500 linhas • Formatação Horizontal ‣Cuidado com scroll horizontal!
  • 47. • Indentação ‣ "Without indentation, programs would be virtually unreadable by humans”
  • 49. Era uma vez uma equipe…
  • 50. … que não se importava com a qualidade do código de testes.
  • 51. Com o passar das releases, o custo de manter a suite só aumentava…
  • 52. … até que tiveram que descartar a suite inteira.
  • 53. Moral da História Código de teste é tão importante quanto código de produção!
  • 54. “Having dirty tests is equivalent to, if not worse than, having no tests.” “What makes a clean test? Three things. Readability, readability, and readability.” Mantenha seus testes limpos!
  • 56. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler “Refactoring is an iterative process full of trial and error, inevitably converging on something we feel is worthy of a professional." - "Uncle Bob" Martin
  • 58. Globalcode – Open4education Obrigado! Stefan Teixeira [email protected] stefanteixeira.com.br @stefan_teixeira