Faz alguns meses, e decidimos, eu e o Emanuel Zabka, implantar o TDD no desenvolvimento na empresa em que trabalhamos. Academicamente é falado muito em refactoring e mudanças de requisitos, mas na prática, eu nunca havia notado a quantidade de modificações que um mesmo código/classe/arquivo é modificado num curto período de tempo e a longo prazo.

Os testes me ajudaram a enxergar, não só as dependências do sistema, como também, acoplamentos desnecessários; a qualidade dos códigos; do design do projeto; e, consequentemente, diminuiu muito os bugs mais corriqueiros, como validação de campos. Mesmo tendo várias coisas boas, há coisas ruins, como aumento do tempo de desenvolvimento – o que, apesar de nunca ter medido, diminui o retrabalho e tempo utilizado no futuro em correções de bugs -, aumento da complexidade da arquitetura – a fim de manter uma maior coesão com baixo acoplamento, entre outros menos relevantes.

Unit Test

The basic concept of unit testing is write more code which will test the main code we’ve written, by “throwing” sample data at it and examining what it gets back.

Harry Fuecks

Enfim, uma boa definição de testes unitários é esta supracitada. São escritos mais códigos para testar o código principal, utilizando dados de testes para analisar o comportamento e o retorno do código sendo testado.

CakePHP

• Framework de desenvolvimento rápido pra Web com PHP
• Utiliza padrões MVC e ORM
• Extensível para desenvolvimento, manutenção e deploying.
• OpenSource / Comunidade muito ativa e amigável
• Orientada a Objetos
• Mais detalhes sobre o CakePHP

SimpleTest

• Praticamente mesma coisa que JUnit, JMock e PHPUnit.
• Guiado através de asserções
• Possibilidade navegação em requisições HTTP para testar interface gerada (HTML)
• OpenSource
• Orientada a Objetos
• Mais detalhes sobre o SimpleTest

CakePHP e SimpleTest

• Startup (criação do arquivo, casos de testes básicos) dos testes unitários automaticamente
• Customizações no template de Report (Web com template padrão)
• Rápida execução de testes individualizados
• Rápida execução de grupos de testes (execução de vários testes unitários sequencialmente)
• Pode-se usar Mock para objetos internos do CakePHP ou da aplicação
• Pode-se testar aplicação toda (APP + Plugins)
• Pode-se testar somente a aplicação (APP)
• Pode-se testar plugins separadamente
• Pode-se testar em modo batch
• Integração dos dois frameworks

Convenções e Padrões

Para o SimpleTest não há padronização no nome dos arquivos, mas o CakePHP estabelece um a partir da convenção das classes utilizados por ele. Ex: respectivamente as classes de controller e model de um Post:

PostController

tests/cases/controllers/post_controller.test.php

Post

tests/cases/models/post.test.php

• O nome da classe contida no arquivo é derivado a partir do nome do mesmo.
• Esta classe deve extender a classe CakeTestCase ou CakeWebTestCase
• A assinatura dos métodos que contém asserções (métodos de teste) devem iniciar com “test”, como em testPostControllerAddPost().
• Métodos que são executados como eventos:

  start()

  Primeiro método chamado. Executado quando se iniciam os testes

  end()

  Último método chamado. Executado quando se concluí todos os casos testes

  startCase()

  Executado antes do caso de teste começar a ser testado (lembrando que um teste pode ser composto de um ou mais casos de teste)

  endCase()

  Executado depois que o caso de teste foi testado por completo

  before($method)

  Anuncia o início de um método de teste

  after($method)

  Anuncia o término de um método de teste

  startTest($method)

  Executado antes de um caso de teste iniciar

  endTest($method)

  Executado depois que um caso de teste termina

Mais detalhes sobre as convenções

Fixtures

Fixtures são uma forma de utilizar dados de teste. São matrizes de dados que correspondem à registros em um banco de dados.
Cada Model possui uma Fixture, que irá não só ter os dados como a representação dos campos que compõe a tabela do banco, pois a partir destes dados o framework irá:

1. Criar uma tabela prefixada (por padrão) de “test_suite_” no banco de dados para cada fixture necessário (ou seja, cada model utilizado).
2. Inserir os dados de teste na tabela de teste
3. Executar os testes em cima destes registros
4. Remover os dados da tabela de teste
5. Remover a tabela no banco de dados.

Ou seja, assim é garantido que os dados serão sempre os mesmos e que não comprometerá a base de dados atual com sujeira, podendo-se executar
estes testes a qualquer momento atrás de problemas. Testes que envolvem banco de dados com índices únicos, chaves primárias ou outras constraints
estão livres de erros (erros não propositais) durante os testes.

Veja mais sobre Fixtures

Asserções

• assertTrue($x)
• assertFalse($x)
• assertNull($x)
• assertEqual($x, $y)
• assertIsA($object, ‘ClassName’)
• assertIdentical($x, $y)
• assertPattern(’/REGEX/’, $x)
• expectError();

Se você se interessou, para mais detalhes sobre os testes unitários no CakePHP, recomendo a leitura deste post da Debuggable: Unit Testing in CakePHP Part 1 – Introduction to Unit Testing

Agradecimentos especiais a André Leitzke e Viviane de Souza por terem me ajudado com a caracterização e descrição do framework!

Primeiro, eu baixei um script que a própria FreeNode.org disponibiliza para o irssi, o instalei e depois algumas dependências.

cd ~/.irssi/scripts/autorun #Se o diretório não existir, crie-o
wget http://www.freenode.net/sasl/cap_sasl.pl

Como maioria das dependências não estavam nos repositórios oficiais do Arch Linux nem do AUR, eu tive que as instalar separadamente e ai já aproveitei pra fazer um script de instalação com todas as dependências. Esse script funciona em qualquer distro. São necessários os seguintes módulos: Math::BigInt, Math::BigInt::FastCalc, Math::BigInt::GMP, Math::BigInt::Pari, Crypt::DH e Crypt::OpenSSL::BigNum.

Abra um novo arquivo e cole as linhas abaixo, será nosso script de instalação.

#!/bin/bash
 
packages=(Math-BigInt-1.89 Math-BigInt-FastCalc-0.19 Math-BigInt-GMP-1.24 Math-BigInt-Pari-1.13 Crypt-DH-0.06 Crypt-OpenSSL-Bignum-0.04)
 
mkdir /tmp/cpan-comp
cd /tmp/cpan-comp
wget http://www.cpan.org/authors/id/T/TE/TELS/math/Math-BigInt-1.89.tar.gz
wget http://www.cpan.org/authors/id/T/TE/TELS/math/Math-BigInt-FastCalc-0.19.tar.gz
wget http://www.cpan.org/authors/id/T/TE/TELS/math/Math-BigInt-GMP-1.24.tar.gz
wget http://www.cpan.org/authors/id/T/TE/TELS/math/Math-BigInt-Pari-1.13.tar.gz
wget http://www.cpan.org/authors/id/B/BT/BTROTT/Crypt-DH-0.06.tar.gz
wget http://www.cpan.org/authors/id/I/IR/IROBERTS/Crypt-OpenSSL-Bignum-0.04.tar.gz
 
for pkg in $packages; do
	tar -xzvf "$pkg.tar.gz" ;
	cd "$pkg" ;
	perl Makefile.PL ;
	make && make test && sudo make install ;
	cd .. ;
done;

OK, o garotosopa tirou toda a graça do meu script, me alertando uma coisa da qual não sabia, para instalar um módulo do perl, basta digitar:

cpan -i Math::BigInt Math::BigInt::FastCalc Math::BigInt::GMP Math::BigInt::Pari Crypt::DH Crypt::OpenSSL::Bignum

Inicie o irssi e digite:

/sasl set freenode Seu_nick Sua_Senha DH-BLOWFISH
/sasl save
/save
/quit

Agora, é só ajeitar o config do irssi.

vim ~/.irssi/config

servers = {
	{
		address = "irc.freenode.org";
		chatnet = "freenode";
		port = "7000";
		use_ssl = "yes";
		ssl_verify = "yes";
		ssl_capath = "/etc/ssl/certs";
	}
}

Entre no irssi novamente e pronto! Só usar o /connect freenode !

E ai, gostou?

Controle de Versão

• SVN Cheat Sheet
• Git Cheat Sheet
• Mercurial Cheat Sheet
• Bazaar Cheat Sheet

Frameworks

• Prototype Cheat Sheet
• MooTools Cheat Sheet
• jQuery Cheat Sheet
• Ruby On Rails
• Django Cheat Sheet
• CodeIgniter Cheat Sheet
• CakePHP Cheat Sheet
• Mais de 12 Symfony Cheat Sheets

Programação

• Bash Script Quick Refences
• AWK Cheat Sheet
• HTML5 Canvas Cheat Sheet
• PHP Cheat Sheet
• Ruby Quick Refence
• 9 Perl Cheat Sheets
• Python Quick Refence
• Regular Expression Cheat Sheet

Web Design

• Font Size Cheat Sheet
• Propriedades CSS
• HTML Char Entities Cheat Sheet
• 6 Design Colors Cheat Sheet
• SEO Web Developer Cheat Sheet

Bancos de Dados

• XML Schema Structure Quick Refence
• MySQL Cheat Sheet
• PostgreSQL Cheat Sheet

Ferramentas

• Google Search Cheat Sheet
• Firebug Cheat Sheet
• Vimperator Cheat Sheet
• LaTeX Cheat Sheet
• Vim Cheat Sheet
• Vim Quick Refence
• mod_rewirte Cheat Sheet

Alguma que eu tenha esquecido? Posta ae nos comentários!

• Certeza de encontrar todas as incidências
• Ficam visualmente destacadas (com :set hlsearch)
• Testar substituições
• Verificar a ortografia atrás de erros de digitação
• Encontrar variáveis ou funções não utilizadas, só declaradas
• Encontrar rapidamente algum termo
• Verificar a existência de algum termo

Além da conhecida / (barra) para buscar, existe o :vimgrep. É dele que quero falar.

Vimgrep

Comando

:vim[grep][!] /{pattern}/[g][j] {files}

• Busca inscidências de pattern nos files listados.
• pattern pode ser uma expressão regular ou não
• A exclamação (!) ignora as alterações já feita no arquivo atual
• g procura por todas as inscidências, não só a primeira, em cada arquivo
• j pula para o primeiro resultado ao executar o comando
• files podem conter wildcards, como *, ? e **
• Os resultados são abertos na quickfix list

Exemplos

:vimgrep! /$var/ arquivo.pl

Pesquisa pela primeira inscidência de $var no arquivo.pl

:vimgrep /texto/ *.rb

Busca por texto em todos os arquivos com a extensão .rb do diretório atual (para descobrir qual o diretório atual, use :pwd. Para mudar :cd dir)

:vimgrep /TeXtO/ *.py dir/*.py

Busca com case-sensitive em todos os arquivos .py do diretório atual e dos dentro do diretório dir/.

:vimgrep /minhaFuncao/g **/*.c

Busca recursiva dentro da árvore de diretórios do diretório atual cuja extensão seja .c

:vimgrep /< \([^ ]\+\)[^>]*>.\+< \/\1>/ index.html

Busca usando expressões regulares também são permitidas!

Navegando na QuickFix List

• :copen
• :cfirst
• :cprevious
• :cnext
• :clast
• :cclose

Como nosso foco é a eficiência, podemos criar mapeamentos para andar pela quickfix list!

map <F9> :copen<CR>
map <F10> :cclose<CR>
map <A-j> :cnext<CR>
map <A-k> :cprevious<CR>

Exemplo de uso do vimgrep

Conclusão

Esse recurso não parece ser muito abordado por ai, mas é extremamente importante. Seja criativo e descubra onde melhor usar o :vimgrep! Tenho certeza de que vai lhe ajudar! E quando encontrar, comente ai!

• screen
• ssh
• vim
• skype

Destas, só o skype não é open-source. Mas é interessante manter uma conversa verbal, pois conversas escritas podem desviar o foco da programação, que é bem mais rápida e precisa do que a escrita, que pode deixar brechas para má interpretações. A conversa verbal consegue interromper o programador ao mesmo tempo em que escreve, corrigindo-o ou questionando-o.

Conectados no skype, basta decidir em qual máquina será o desenvolvimento. Esta, por sua vez, terá que ter um servidor ssh. Ela será o host da programação. Será necessário, também, nesta máquina, ter instalado o screen, que é um programa que possibilita criar ’sessões’ no terminal.

Host

screen -S PairProgramming

Parece que nada mudou, mas você está numa sessão do screen chamada PairProgramming.

Precione CTRL+a e digite:

:multiuser on

Pressione CTRL+a novamente e digite:

:acladd usuarioclient

Tudo que você ver nesta sessão, será visto pelo outro usuário (usuarioclient) que se conectará nela.

Então, abra o vim, pois será necessário um edito de textos de verdade , e se divirta:

vim /caminho/arquivo

Client

ssh usuarioclient@host
screen -x usuariohost/PairProgramming

Pronto! Agora você está acessando a mesma seção! Tudo que o usuáriohost fizer, o usuárioclient enxergará e vice-versa.

Agora, basta descutir a tarefa via Skype e programar. As atualizações são em tempo real, ou seja, aparecem ao mesmo tempo que são escritos, digo… depende da conexão, mas não é um grande problema.

Caso seja necessário que o usuarioclient não possa modificar o código, apenas assitir e dar pitacos, o usuáriohost deve pressionar CTRL+A e digitar:

:aclchg usuarioclient -w #

Eu ainda vou programar assim, depois digo a experiência.

Referências

• Linux.com
• Jason Haruska

Baseado nisso e no comentário que recebi recentemente e inspirado pelo post de um amigo, vou fazer uma lista de coisas que proponho. São coisas simples, mas que facilitam na manutenção.

Umas das coisas que aprendi com Uncle Bob (Robert C. Martin), no seu livro Clean Code foi: escrevemos o código apenas uma vez, porém o mesmo é lido várias vezes. Então, não custa usarmos 5min a mais documentando alguma coisa ou escrevendo variáveis legíveis, que nos pouparão tempo mais tarde!

1. Clareza e objetivadade nos nomes das variáveis

É incrível como as pessoas conseguem dar nomes criativos para variáveis. O alfabeto tem tantas letras que formam tantas palavras, por que insistem em usar apenas 1 letra como nome de variável? Pior, Por que usar sempre as mesmas?

$d = 3;
$dias = 2;

A primeira variável simplesmente não diz nada. Olhando ela não se consegue ter noção nenhuma do que ela representa, o que é o 3? Do mesmo modo se aplica a segunda variável, sabemos que são 2 dias, mas 2 dias não nos diz nada também. Olhando assim, só sabemos a unidade de medida!

$dia_vencimento = 3;
$qtde_dias_para_pagamento  = 2;

Há quem reclame do tamanho das variáveis. Mas hoje em dia, que editor não auto-completa para você? Se o seu não, por favor, considere trocar =).

O que se deve cuidar ao se nomear uma variável, é não por algum nome que venha a ter mais de uma possibilidade de significado. Por exemplo:

$valor_frete_desconto = 11.3;

O valor acima citado, é referente ao desconto dado ao frete, ao valor do frete a ser descontado ou o valor do frete com o desconto? Eu não afirmo nenhuma hipótese à partir do nome dado. Se me perguntarem, eu diria que olharia o código para afirmar. Por tanto, seja CLARO E OBJETIVO.

$valor_frete = 13.4;
$valor_desconto_frete = 2.3;
$valor_frete_descontado = $valor_frete - $valor_desconto_frete;

Caso o desconto do frete seja aplicado com porcentagem:

$pct_desconto_frete = 10;
$valor_frete = 13.4;
$valor_desconto_frete = $valor_frete * ($pct_desconto_frete / 100);
$valor_frete_descontado = $valor_frete - $valor_desconto_frete;

A melhor coisa em relação às variáveis é justamente o fato de omitir o valor atrás de um nome inteligível. Por tanto, sempre que possível, esconda os valores, a legibilidade aumenta muito!

    $arr_usrs = array();
    for ($i = 0; $i < count($users); $i++) {
        if ($users[$i][3] == 4)
            $arr_usrs[] = $users[$i];
    }
    return $arr_usrs;
}

Pergunto:

• $arr_usrs é uma lista gerada à partir de que dados?
• O que é o índice 3 do array usado no if ?
• O que diabos quer dizer == 4?
• O que devo esperar que $arr_usrs contenha?

define("STATUS", 3);
define("ATIVO", 4);
    $contatosAtivos = Array();
    for ($i = 0; $i < count($contatos_do_usuario); $i++) {
        $contato = $contatos_do_usuario[$i];
        $status_do_contato = $contato[STATUS];
        if ($status_do_contato == ATIVO)
            $contatosAtivos[] = $contato;
    }
    return $contatosAtivos;

Acho que não preciso explicar o código, não é?

Outra coisa interessante, CUIDADO com as variáveis de duplo sentido.

$total = count($usuariosDoBanco);

$total recebeu o total de usuários do Banco de Dados ? o total de usuários de um determinado banco (BB, Santander, etc) ?

Sugestão:

$total = count($usuarios_cadastrados);

ou, para o outro caso

$total = count($clientes_santander);

Eu sei que muitas vezes é difícil escrever códigos de forma bonita, mas o esforço vale a pena! Além de ser um diferencial profissional, trabalhar no meio da zona é prejudicial a você mesmo!

Lembrou de algo? Tens outras dicas? Comenta aê!

Quando eu vou escrever em algum programa de qualquer suíte de escritório – openoffice, koffice, etc -, eu geralmente me preocupo mais com o negrito da palavra, com identação do parágrafo do que com o conteúdo em si. Isso é um pecado.

Meu primeiro instinto foi: vou escrever tudo no Vim, depois colo no Impress. Boa! Ok, mas e quanto às páginas?
Vou ter que por página por página? Ainda sim eu teria mais trabalho. Eu teria que refazer as listas para que ficassem com as “bolinhas” à esquerda. E teria que modificar todos os títulos para negrito?

Fui pro google e achei um plugin que já conhecia no resultado: VimOutliner. Ele dita uma sintaxe muito intuitiva para hierarquisar (existe esse verbo?) o conteúdo. Algo assim:

Título do documento
 
Tópico Nível 1
	Tópico Nível 2
	: Parágrafo com alinhamento justify
	; Parágrafo fica do jeito que foi escrito
	- Item de lista
	+ Item de lista numérica

O plugin vem com documentação e um shell script que instala automaticamente o plugin. O site tem toda documentação, é bem simples.

Em http://perens.com/FreeSoftware/Outline/ é possível encontrar vários scripts que convertem o documento para outros formatos. Um deles é o vo2odp.rb, um script em ruby para converter arquivos para o OpenOffice Presentation.

Pra fazê-lo rodar, eu sofri um pouquinho. Tive que instalar o ruby (obviamente) e o rubygems. Depois de instalado:

$ gem install builder
$ gem install rubyzip

Também alterei o script, segue o patch das modificações:

29,30c29,30
< require_gem 'builder'
< require_gem 'rubyzip'
---
> require 'builder'
> require 'zip/zip'

Copie o trecho acima em um arquivo, por exemplo: /tmp/patch_vo2odp, depois execute

$ patch /caminho/para/vo2odp.rb < /tmp/patch_vo2odp

Pronto, agora só escrever sua apresentação. Lembre-se que o plugin tem uma extenção própria, a .otl. Sempre que um arquivo for aberto com esta extenção, o Vim irá carregar o syntax highlight apropriado e algumas outras opções para melhor escrever sua apresentação.

Concluída a apresentação, você pode usar

$ ruby /caminho/para/vo2odp.rb apresentacao.otl apresentacao.odp

Abra com o OpenOffice e salve como .ppt. Pronto! Você acabou de fazer sua apresentação no PowerPoint pelo Vim.

Observações importantes

• O script não quebra as páginas dos slides automaticamente. É separado por capítulos de nível 1. Então, não escreva coisas muito longas dentro de um nível. Lembre-se que é uma apresentação e não um documento de texto.
• Quando aberto no OpenOffice, use o negrito, sublinhado, coloque imagens, etc. Crie seu layout e não pense nisso durante a criação do conteúdo. Escreva antes e formate depois

E isso ai! Gostou? Não? Comente! Dê dicas e sugestões!

Ingredientes

• Lazanha
• Python instalado
• 3 minutos de lazer

Modo de preparo

Pegue os 3 minutos de lazer e utlize para criar um diretório:

$ mkdir ~/htmldocs
$ cd ~/htmldocs
$ echo "<html><head></head><body>Meus posts no blog</body></html>" > index.html
$ python -m SimpleHTTPServer
$ firefox http://localhost:8000

Pronto! Agora você pode gerenciar documentações, fazer preview de posts no seu blog, fazer testes de javascript/css sem precisar instalar o apache ou criar um VirtualHost!

Eu achei útil! E você?