KISS - Keep it simple, stupid!

Recentemente encontrei um site muito interessante de desenvolvimento de testes automatizados, o site dispõe de diversos assuntos importantíssimos para quem quer aprender e se aperfeiçoar em desenvolvimento de teste. Lendo alguns textos, fiquei com vontade de comentar aqui o “Goals of Test Automation”. O capítulo enumera 6 grandes objetivos para se ter sucesso no desenvolvimento de testes unitários e testes de aceitação, não explicando como alcançá-los.

Tive a idéia de escrever aqui uma releitura do texto utilizando os 3 primeiros grandes objetivos como motivações, benefícios que os testes podem trazer para o projeto. A idéia é plantar uma semente naqueles que ainda não acreditam nos testes, tentar mostrar que, quando bem implantado, os testes são valiosos.

1- Melhoria da qualidade

Antes de falar sobre como o teste pode ajudar na melhoria da qualidade, temos que entender o que significa qualidade de software. O autor foi muito feliz quando dividiu o definição de qualidade em dois tópicos: o software foi desenvolvido corretamente? desenvolvemos o software certo?

Quando desenvolvemos testes, buscamos sempre pensar em qual o comportamento que nosso código deverá ter em diversas situações.  Se conseguirmos escolher corretamente as situações que correspondem o que o cliente precisa e reproduzirmos estas situações nos testes automatizados, teremos certeza que os comportamentos serão atendidos e que estamos no caminho certo. As ferramentas de testes de aceitação são ótimas para atingirmos este objetivo.

Desenvolvendo que é realmente necessário, devemos garantir que o software realize corretamente os comportamentos. Nosso código deve estar livre de qualquer Bug. Testes unitários são ótimos para encontrar Bugs e prevenir que eles retornem. Quando um teste falha, a suíte nos indica precisamente o local que ocorreu o erro, nos dando informações valiosíssimas para concertamos o problema. Isto em questões de segundos.

As vezes, o Bug é descoberto quando o sistema está em produção, nestes casos o estrago provavelmente já deve ter ocorrido. Mas a automação ainda pode ser útil, temos a possibilidade de criar a reprodução do problema com um teste (Regression Test) e, assim prevenir,que o Bug retorne em futuras modificações.

Vale comentar que desenvolver teste é como desenvolver código, da mesma maneira que podemos cometer alguns enganos na programação de uma função, os testes também sofrem este problema. A diferença é que sem testes, o tempo e custo para encontrar estes enganos seriam muito maior.

2- Entendimento do Sistema

Quem estuda metodologia ágil deve conhecer o manifesto que prega, entre outros,  “código funcionando mais que documentação”. É com esta filosofia que digo: Uma suíte de testes é ‘n’ vezes mais valiosa para o entendimento que qualquer documentação.

O primeiro benefício é que os testes não ficam “desatualizados”, eles correspondem fielmente o que o código realiza. A documentação de um sistema é um custo para o projeto que, quando o prazo está curto, o sistema está com bug e o orçamento está no fim, a primeira atitude dos desenvolvedores é cortar esse peso. Uma documentação desatualizada é pior que não ter documentação. Testes e código não mentem, eles são, até certo ponto, exatos.

Temos que lembrar também que testes são códigos, e nós somos autores de códigos. Nós sabemos ler e escrever código, não documentação. Isto leva àquela velha história de comunicação, onde um desenvolvedor, ao escrever a documentação, não consegue expressar o que o código reproduz e escreve algo que não condiz com o sistema, seu colega, como muitos analfabetos funcionais, não interpreta corretamente o que o primeiro escreveu e entende algo totalmente diferente que realmente o código está fazendo. Resumindo, uma grande piada, que para o cliente é de extremo mal gosto.

3- Redução de Riscos

Uma das grandes vantagem dos testes é a criação de uma rede de proteção. Esta rede te dá liberdade para evoluir o sistema sem medo de ser feliz. Já comentei sobre desenvolvimento confiante aqui no blog. Com uma rede de proteção podemos nos prevenir de bugs já conhecidos, mexer em códigos legados e adicionar novas funcionalidades sem medo, pois sabemos que tudo que fazemos, temos os testes para verificar se estragamos algo. É isto que chamamos de Risco Calculado.

Os outros 3 grandes objetivos citado pela fonte diz mais a respeito dos testes em si, algo que deixarei para comentar em uma outra oportunidade. Meu foco foi trazer para vocês os que os testes podem fazer pelo sistema, os benefícios que recebemos quando desenvolvemos testes automatizados de forma correta. Fica o convite a todos para lerem o texto original, tenho certeza que não se arrependerão.

Somente para divulgação, o Renan Gonçalves está organizando um evento sobre CakePHP em São Paulo. Pelo que ele está diz no blog, o evento é diferenciado por tratar o CakePHP como o foco principal, contrapondo com as típicas apresentações de “Introdução ao CakePHP blábláblá” by Renan em eventos aleatórios.

Eu realmente não sei se conseguirei ir mas se a grana der estarei lá marcando presença! Só para completar o aviso, o Renam convocou todos que estão interessados pelo evento para escrever um comentário no blog dele, assim ele poderá mensurar um tamanho para o evento.

Uma das grandes dificuldades dentro de um time de desenvolvimento WEB, sem dúvida, é manter o Banco de Dados atualizado entre todos ambientes de trabalho. Volta e meia um desenvolvedor faz alguma alteração no banco e não comunica o restante do grupo. Isto sempre causa retrabalho, bugs ou um programador arrancando o próprio cabelo.

Uma das causas deste problema é que em nenhum momento rastreamos as modificações do banco em nossos projetos. Para o código temos o SCM (source code management), para controlar as tarefas temos os gerenciadores de projetos, para os documentos temos o Google Docs, mas para o banco de dados? Foi pensando nesses problemas que se criou o técnica de Migrations. O Migrations é uma forma de manter organizadas as modificações na estrutura do banco de dados, permitindo, dentre algumas facilidades, construir seu banco incrementalmente, retroceder alteração que não sejam mais adequadas ou trabalhar em ambientes com diversos programadores.

O conceito básico de Migrations consiste em armazenar as modificações do banco em pequenos arquivos numa ordem cronológica. Esses arquivos devem conter informações que consigam construir ou destruir seu banco de uma versão para qualquer outra. Como se faz isto? Simples, indique no seu arquivo como proceder numa determinada atualização (UP) e como retroceder (DOWN), assim, quando quer ir para uma versão mais nova, execute todos os UPs dos arquivos mais recentes, e quando quer retroceder, execute os DOWNs até a versão mais antiga. Com ajuda de um programa auxiliar, que geralmente é um automatizador, você consegue executar facilmente tarefas como (re)construção de banco, atualização de alterações ou rollback’s de algo que não saiu como se devia.

Em algumas implementações de Migrations é possível fazer manipulação de dados. Esta é uma facilidade muito interessante e os DBA’s devem adorar. Imagine que você, em um determinado momento, queira fazer uma modificação no campo “nome_completo” quebrando-o em dois: “nome” e “sobrenome”. Com a manipulação você consegue fazer o tratamento dos dados e migrar, não só a estrutura do banco, mas também os dados que por ventura podem estar armazenados. Esta funcionalidade dá um pouco mais de poder ao Migrations, mas nem sempre esta presente em todas as implementações.

Como alguns podem estar acompanhando, eu e Juan Basso estamos criando uma implementação de Migrations para CakePHP. Numa iniciativa de não tentar reinventar a roda, estamos fazendo alguns estudos sobre implementações de Migrations em PHP. No momento temos três implementações que acreditamos ser interessantes: CakeSchema, Migrations do JoelMoss para Cake e o Ruckusing. Cada um possui qualidades e defeitos, por isso tivemos a idéia de convidar a comunidade para discutir a necessidade de se criar uma nova implementação. Quem puder nos ajudar testando estas implementações e nos falando seus pontos pró e contras, ou mesmo apontando outras implementações, agradecemos.

Bem, está ai uma breve explicação de Migrations, espero que você tenham entendido um pouco e estamos esperando a participação de todos na discussão.

Venho acompanhando recentemente as mensagens relacionadas ao CakePHP no Twitter e estou surpreso! Como é interessante ver a “mundo” do CakePHP em 140 caracteres.

Eu uso esporadicamente para falar o que estou fazendo (mas quem quiser adicionar), mas sempre curti acompanhar alguns Twitters que acho interessante. Com o Twitter parece que estou na “crista da onda”, Blogs são tartarugas comparados com ele.

Dia destes, lendo meus feeds conheci o Timeline do CakePHP, uma ferramenta para visualizar as twitadas dispostas numa linha do tempo. Muito legal visualmente mas o importante mesmo foi o que eu notei: existe muita gente escrevendo sobre CakePHP e, o que é mais legal, muita coisa boa! Por isso não perdi tempo, adicionei o RSS de todas as mensagens do CakePHP no Twitter.

Ai vocês devem estar se perguntando: “Ele é doido? Quanto isso dá de mensagem por dia?”. Bem, devo ser um pouco doido sim, mas vale a pena. Só para ter uma idéia, descobri que a empresa Criasol está em busca de desenvolvedor WEB com conhecimento em CakePHP, legal né? Sem contar os depoimentos constantes e super engraçados de pessoal que estão começando a utilizar o framework, imperdível.

Sem dúvida, mais uma maneira de se manter antenado no mundo CakePHP. Para aqueles que tem um tempinho para ler umas 150 twittadas por dia, é um prato cheio! =D

Sempre tive dificuldade de utilizar o GitHub aqui na faculdade, infelizmente aqui tem um proxy filho da pu.. que, além de bloquear alguns sites “legais”, desabilita quase todos os protocolos que não sejam HTTP, HTTPS e FTP. E adivinha? Nada de GitHub pro papai aqui.

Bem, meu problema acabou! Buscando algumas informações sobre como utilizar GitHub dentro de proxy, encontrei este artigo do tycho. O método dele é simples, ele utiliza uma facilidade do GIT que permite você indique um comando para tunelar o protocolo git://, que geralmente é trafegado pela porta 9418 (by thyco), isto dá a possibilidade de utilizar algum programa ‘burlador’ de proxys, como Your Freedom, para transitar suas requisições GIT.

O procedimento é um pouco complexo (pelo menos para mim, acho que foi a primeira vez que dei um make sozinho) e eu não faço a mínima idéia de como realizar isto no Windows, mesmo assim tentarei explicar. Faça o download do repositório tycho/connect (não dê ‘git clone’ pois, se está lendo este artigo, você não pode dar um ‘git clone’). Descompacte os arquivos numa pasta e dê um make dentro do diretório. Isto criará um comando chamando ‘connect‘, você pode colocar esse comando em alguma pasta que esteja referenciado no seu PATH ou deixá-lo onde quiser para acessá-lo diretamente.

A segunda parte é a configuração do GIT. Edite o arquivo gitproxy que veio junto com o repositório do thyco e certifique-se que o comando connect será executado em qualquer lugar. O que isto quer dizer? Se você colocou no PATH, você não faça nada, se você quis acessar diretamente, coloque o caminho completo do connect. Agora, você deve indicar qual o comando o GIT deve utilizar para tunelar o protocolo git://, veja abaixo como proceder:

git config --global core.gitproxy PATH/gitproxy

Novamente temos a situação onde podemos colocar o comando gitproxy em algum PATH ou indicá-lo diretamente, vocês já devem estar entendendo =D. O –global é opcional, mas acho que todos deixarão para não ter que configurar cada repositório manualmente, certo?. Bem, por último coloque o YourFreedom para rodar, certifique-se que o SOCK está rodando na porta 1080 (se não tiver, modifique o gitproxy) e voy lá, agora você pode mandar o proxy catar coquinho!

Sem dúvidas isto foi um life-changer para mim, fazia tempo que estava tendo problemas com este proxy. Acredito que esta dica ajudará muita gente, pois tenho certeza que aqui na empresa irá beneficiar uns 5!

Certo dia, lá no canal do IRC fiquei sabendo de um projeto muito interessante, o CakeAutoTest do Rodrigo. Se trata de um plugin de CakePHP para realizar Auto-Testes. Não sei se comentei aqui no blog mas sempre acreditei que teste automatizado é a melhor ferramenta de feedback que podemos ter num projeto, ele nos dá confiança para prosseguirmos, coragem para refatorar nossos códigos, simplicidade e motivação para não pararmos de programar. E se feedback é tão bom, por que não termos esse feedback a todo momento!? É esta a idéia do AutoTest.

CakeAutoTest em Ação!

Depois que soube que ele tinha iniciado este projeto, fiquei muito empolgado para poder utilizar. Infelizmente acabei tendo alguns problemas e não tive muito tempo para explorar o plugin. Bem, a espera terminou, fiz um fork no projeto e arregacei as mangas para solucionar alguns dos problemas que estava enfrentando, de quebra, acabei fazendo um pouco mais e adicionei suporte a uma ferramenta de notificação para o Linux (libnotify).  As minhas modificações já foram adicionadas no repositório principal do Rodrigo. Para instalar o Libnotify no Linux é fácil, com o ’slapt-get’ do Slackware é só fazer o download dos pacotes libnotify-0.4.*as e notification-daemon-0.4.*as (em outras distros eu não faço idéia como instalar).

Após fazerem clone no projeto do Rodrigo ou no meu na pasta de plugins vocês devem configurar o arquivo .autotest do seu projeto (crie um arquivo .autotest na raiz da pasta /app). Neste arquivo a idéia é armazenar as informações singulares de cada projeto, como as pastas que serão ignoradas e/ou o sistema de notificação que irá utilizar. Para vocês terem uma idéia, este arquivo será carregado dentro do __construct() do AutoTestShell, portanto vocês poderão setar/utilizar qualquer variável da classe. Como exemplo, vocês podem olhar o .autotest que utilizo:

<?php 
$this->ignore_files[] = '/autotest/';
// Adicionando a notificação do LibNotify
include( $this->paths['libs'].'libnotify.php');
?>

Para executar é simples, chame a Task autotest no Shell do CakePHP e deixa rolar. A cada modificação em qualquer arquivo do projeto, o plugin irá rodar os testes. Se você quebrou ou concertou algum teste, ele avisará. Simples e super útil! Agora, tudo que você fizer no projeto você terá o feedback se está melhorando ou estragando tudo!

Está ai a apresentação desta nova ferramenta para CakePHP, parabéns ao Rodrigo e qualquer dúvida que vocês tiverem é só comentar no post que terei o prazer de ajudar!