Transferir como PDF, PPTX
Carregado porStefan Teixeira
TDC 2014 POA - Clean Code para Testers
O documento discute os princípios do Clean Code e como aplicá-los para manter código de teste limpo e de alta qualidade. Ele apresenta seis pontos importantes: 1) usar nomes significativos; 2) criar classes pequenas; 3) criar funções pequenas e focadas; 4) usar comentários de forma apropriada; 5) seguir boas práticas de formatação; 6) tratar os testes como código importante e mantê-los limpos. O objetivo é produzir código que seja fácil de ler, modificar e dar manutenção.
Mais conteúdo relacionado
![Técnicas de frontend para aplicações django - PythonBrasil[9]](https://cdn.slidesharecdn.com/ss_thumbnails/tcnicasdefrontendparaaplicaesdjango-pythonbrasil9-131119065900-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Semelhante a TDC 2014 POA - Clean Code para Testers
TDC 2014 POA - Clean Code para Testers
- 1. Clean Code paraTesters Globalcode – Open4education Stefan Teixeira stefanfk@gmail.com / stefanteixeira.com.br
- 2. Sobre o palestrante Stefan Teixeira! • QA Engineer! • Bacharel em Ciência da Computação pela UFRJ! • Finalizando MBA em Garantia de Qualidade de Software pela Escola Politécnica da UFRJ! • Mantém um blog técnico sobre testes: stefanteixeira.com.br! • Certificado CTAL-TM / TA pelo ISQTB e CPRE-FL pelo IREB! 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
- 3.
- 5. Quando comecei aler o livro
- 6.
- 7. Por que CleanCode?
- 9. O custo decó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 ScoutRule! “Leave the campground cleaner than you found it."
- 15. 6 pontos sobreClean Code importantes para um tester
- 16.
- 17. Use nomes querevelem 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 classese 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
- 20.
- 21. Não crie classesMegazord!!
- 22. Classes devem serpequenas!! ! “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."! !
- 24.
- 25. Cuidado com osZords…!
- 26. Funções devem serpequenas!! ! ! “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 umacoisa!! ! 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 umacoisa!! ! • 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. Como saber sea 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."
- 31. DRY (Don’t RepeatYourself)! 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; }
- 32. DRY (Don’t RepeatYourself)! 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(); }
- 33.
- 34. ! ! “Don’tcomment 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.”! ! !
- 35. 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
- 36. Comentários BONS! •Aviso sobre consequências! !
- 37. 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(); }
- 38. 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(); }
- 39. Comentários RUINS! •Noise comments (reafirmam o óbvio)! /** * Retorna o nome * @return o nome */ public String getNome() { return nome; }
- 40. 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. :)
- 41. Comentários RUINS! •Comentários em HTML
- 42. Comentários RUINS! •Comentários extensos
- 43.
- 44. • 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.
- 45. • 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!
- 46. • Indentação! ‣"Withoutindentation, programs would be virtually unreadable by humans”
- 47.
- 48. Era uma vezuma equipe…
- 49. … que nãose importava com a qualidade do código de testes.
- 50. Com o passardas releases, o custo de manter a suite só aumentava…
- 51. … até quetiveram que descartar a suite inteira.
- 52. Moral da História! ! ! ! Código de teste é tão importante quanto código de produção!
- 53. “Having dirty testsis equivalent to, if not worse than, having no tests.”! ! “What makes a clean test? Three things. Readability, readability, and readability.”! ! Mantenha seus testes limpos!
- 54.
- 55. “Any fool canwrite 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
- 56. Globalcode – Open4education ! Obrigado!! ! ! Stefan Teixeira! stefanfk@gmail.com! stefanteixeira.com.br! @stefan_teixeira