Perdido no TDC-SP22/07/2015 – Trilha de testes [parte 2 de 3]

Olá!

Se você ainda não viu a primeira parte dos posts do TDC, aconselho a leitura para ter uma visão melhor do que aconteceu no evento.

Nesse post vou comentar um pouco sobre a palestra do Stefan Teixeira, que fala sobre Clean Code para testers.

Como os slides estão aí, não vou entrar tanto nos detalhes sobre o que foi dito no dia, mas gostaria de atentar o por que de eu ter escolhido essa palestra… você que está começando a estudar sobre testes pode estar pensando algo como

“Mas poxa, isso é basicamente para melhorar os códigos que eu escrevo….mas eu nem escrevo códigos ainda…. isso ‘é muito complicado para estar aqui!”

E sim…você está com a razão, pelo menos até certo ponto. A automação muito provavelmente vai se tornar parte da sua rotina de testes futuramente, então você vai se deparar com códigos, vai ter que criar alguns inclusive… e nesse momento essa palestra pode ser útil! E antes que você argumente com “Mas isso só la na frente…não preciso ver isso agora”, lembre-se que é mais fácil começar já conhecendo as boas praticas do que tentar corrigir alguns “vícios” que por ventura sejam criados durante o aprendizado. Além disso, essa palestra é interessante não só para testers, mas para desenvolvedores no geral.

Resumindo, escolhi essa palestra para que essas ideias fiquem memorizadas para quando começarmos a mexer em códigos lá na frente, e tem um outro motivo que vai ficar mais fácil de entender no final do post

Agora, vamos a um resumo bem simples da palestra:

“Um código limpo sempre parece que foi feito por alguém que se importa.”

-Michael Feathers

E se nós nos importamos com a aplicação que vai ser entregue ao cliente, vamos começar demonstrando isso no código.

Lembrando que não tenho muitos conhecimentos sobre desenvolvimento, logo o resumo não vai ser tão proveitoso quanto a palestra em si, então vejam os slides que compartilhei no começo do post.

6 Pontos importantes sobre Clean Code

1 – Nomes significativos :Num código nós damos nomes aos métodos, strings, classes… bem nomeamos tudo para facilitar a nossa vida, para não ter que ficar digitando um monte de coisa repetida nós simplesmente damos um nome para aquilo e chamamos sempre que precisarmos. Vou usar um exemplo bem simples, digamos que eu vou fazer um app que vai trazer algumas receitas, uma delas é um “Misto-quente”, esse misto quente precisa de 2 fatias de pão, 2 fatias de presunto, 2 fatias de queijo, uma rodela de tomate, uma colher de chá de orégano. Essa receita em específico vai ser usada várias vezes no app, então ao invés de digitar todos os ingredientes toda vez que eu for usar ela, eu posso simplesmente chama-la de “misto-quente”, e digitar o nome dela no meu código, e ela já vai trazer todos os ingredientes….

Agora, você não concorda que se você for ler meu código vai ser muito mais fácil reconhecer essa receita se eu chamar ela de “Misto-Quente” do que de “Receita03219”? Então, se você colocar nomes significativos vai facilitar a vida de todo mundo que for ler o código, que não vai ter que ler e re-ler até entender o que “aquela receita” é na verdade.

2 – Classes: As classes tem que ser pequenas, simples assim…e se quiser melhorar elas, diminua ainda mais… Eu infelizmente vou ficar devendo uma explicação sobre classes no momento, não entendo elas o bastante para explicar (aceito ajuda nos comentários inclusive rs).

3- Funções: As funções devem ser curtas, fazer apenas uma coisa e ter um nome descritivo…A “função” dentro de um código tem uma função, sim é exatamente o que o nome diz…. você croa um bloco no código que vai exercer alguma função dentro dele…. é como se ao invés da receita eu tivesse agora o “Preparar misto quente”, e quando eu acionar essa função dentro do meu código, ela vai me preparar o misto quente (pra isso dentro dela eu vou ter que colocar o passo-a-passo da forma de preparo), mas não seria interessante ter uma função “preparar misto quente e hamburguer”, seria melhor ter uma função pra cada receita, e chamar as duas quando precisar.

4- Comentários: Você sabia que pode colocar comentários no seu código? Eles estão lá para que qualquer pessoa que acesse o código possa ler, mas o computador ignora completamente esses comentários. Se você procurar algumas pérolas desses comentários vai achar várias… coisas como “eu não sei o que essa função faz”, “não mexe nessa linha pelo amor de Deus!” entre outras coisas do gênero… e é uma tentação grande colocar esses comentários, mas usem eles das formas certas… se você precisa de um comentário para explicar o que uma função faz, então a função não está boa o bastante…  por exemplo a função “Receita 987737” tem um comentário que é “Essa função chama a receita do bolo de fubá”, seria bem mais simples a função se chamar “Bolo de fubá”! Bem nos slides existem vários exemplos legais de comentários que podem/devem ser usados (exemplo CopyRights), e eu gosto de usar eles pra estudar…como lembretes dentro do próprio código, mas aí já é um código com fins de estudo….só tomar o cuidado para não mantes essa mania.

5- Formatação: Se você pegar um código qualquer e deletar todos os “Enters” e “Tabs”, não vai mudar em nada a funcionalidade do app… mas coitado de quem tiver que mexer nesse código depois.. a máquina entende, nós não… Então organize seu código de uma forma agradável e principalmente LEGÍVEL! Coloque os espaços, pule linhas, não faça um texto gigante pra pessoa ter que usar a barra de rolagem para o lado… por aí vai.

6- Testes:  Código de teste é tão importante quanto código de produção, façam eles com qualidade!

Agora aquele outro motivo de eu ter postado essa palestra aqui, vocês perceberam que isso não passa de um manual de boas práticas certo? Algo como “Faça um código que as outras pessoas possam entender sem muitos problemas”, e que fala basicamente sobre programação… mas por favor, tentem levar isso para outras situações… por exemplo um caso de teste, ou o report de um Bug… façam com que o nome do Bug já seja o bastante para a pessoa saber sobre o que se trata, que ela não tenha que entrar na descrição dele pra entender, por exemplo:

Bug01 – Página do aplicativo está com problema.

Bug001- A página “Contatos” do aplicativo apresenta texto inesperado.

Qual deles é mais fácill de entender? Ao meu ver o “001”e dentro dele eu apontaria aonde exatamente o erro acontece, e qual o texto que aparece… O ponto é, você provavelmente não trabalha sozinho, lembre-se de que aquilo que você faz é para a equipe, e não para você, faça com que seja simples para todos, isso economiza tempo e evita retrabalho.

Não mantenha suas boas práticas apenas no código, mas em tudo que for possível. 😉

No próximo post irei comentar sobre outra palestra que presenciei no TDC 😉

Anúncios

Um comentário sobre “Perdido no TDC-SP22/07/2015 – Trilha de testes [parte 2 de 3]

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s