Este ano esteve em destaque a PHPTestFest09, sendo realizada em vários cantos do mundo e destacando-se a participação do PHPSP que contribuiu com o maior número de testes. Ficou de fora? Então já comece a se preparar para ano que vem.

O PHPT é um framework extremamente simples de testes criado e usado internamente pelos desenvolvedores do core. Ele é extremamente atômico e centrado em testes como os que esperamos do PHP, como testar funções e bugs específicos.

O que preciso saber?

A grande vantagem do PHPT é que para poder escrever um teste, tudo que você precisa saber é: como escrever código PHP. Claro que um pouco de conhecimento interno do funcionamento do PHP vai te ajudar a procurar detalhes para testar, mas sabendo escrever PHP você já pode contribuir com uma grande percentagem dos testes que precisamos.

Vamos então atacar por partes:

1. Preparando o ambiente
2. Escolhendo um teste
3. Escrevendo um teste
4. Rodando um teste
5. Enviando seu teste para o PHP

1. Preparando o Ambiente

A preparação do ambiente não é nada complicada e exemplos estão disponíveis para referencia. A primeira coisa que você precisa é da versão do PHP que vai precisar para rodar testes. No caso do TestFest focamos no PHP 5.3, no momento recomendo pegar as últimas disponíveis na página do PHP QA (qa.php.net) vá lá e baixe o pacote (source ou binary para windows).

Em ambientes Linux/Mac Os X, você irá passar pelo processo de compilar o PHP, passando pelos processos normais de “./configure”, “make” mas antes de rodar o “make install”, você poderá rodar o comando “make tests”. Este comando irá rodar todos os testes do PHP (em torno de 900+), pode demorar, mas é um ótimo procedimento, pois ao final você poderá mandar um relatório para a equipe de QA e “fazer sua parte”. Rode também o comando make install pois durante a confecção de um teste será interessante você poder testar ele com a versão correta do PHP.

Mais pra frente vamos ver como usar o make tests para rodar os seus novos testes.

2. Escolhendo um teste

Antes de escrever um teste é necessário escolher o objeto de nosso teste. Para tal é preciso identificar um ponto do PHP que necessita de um teste, isto pode vir de duas fontes, um bug ou uma linha de código não “coberta” (code coverage). Para descobrir bugs com/sem testes a melhor forma é olhando a pasta de testes da extensão do bug (GD -> /ext/gd/tests) ou conversando com o pessoal na lista do QA.

Para testes específicos de linhas de código sua melhor aposta é o site http://gcov.php.net onde você deve navegar até a versão correta que esta testando e então escolher uma área sem cobertura. No caso da testfest deste ano, o PHPSP focou na GD pois sua cobertura estava bem baixa então navegamos até o gcov do gd.c para ver onde poderiamos atuar. Para fazer esta parte do processo um conhecimento básico de C e de como o PHP funciona por baixo dos panos é muito bom, mas após alguns testes você aprende a identificar os pontos e durante o testfest o Guilherme Blanco e o Erick nos ajudaram a entender o código.

Para exemplificar melhor vamos ver como identificar estas linhas e o que elas fazem. Veja por exemplo a linha abaixo:

O que queremos é que todas as linhas fiquem azuis (executadas) ou brancas (código não executável), as linhas não testadas estão marcadas de vermelho. Identificando a linha 1856 como não executada devemos interpretar que como há um if logo antes, a condição “== FAILURE” nunca é atingida, ou seja, esta linha nunca é executada pois a função zend_parse_parameters não retorna falso em nenhuma das chamadas a função imagecolorallocatealpha identificada logo ali encima na linha 1848.

Mas e ae? Ok, a função zend_parse_parameters é responsável por validar os parâmetros da função, ou seja, para testar esta função precisamos escrever alguns testes que passem parâmetros inválidos para a função e verifique se ela alerta o erro corretamente. Agora podemos passar para o passo de escrever este teste.

3. Escrevendo um teste

Escrever um teste é incrivelmente simples, e como testes devem ser objetivos e pontuais isso é bem claro. Você deve limitar o escopo de seu teste, procurando testar apenas uma função ou aspecto. Isso irá facilitar a nomeclatura de seu teste.

3.1 Nomeclatura de arquivos

A nomeclatura é bem simples:

• Teste para bug: bug<bugid>.phpt
• Funcionamento básico da função: <função>_basic.phpt
• Erros da função: <função>_error.phpt
• Variação do funcionamento da função: <função>_variation.phpt
• Extensões: <extensão>_<#>.phpt

3.2 Estrutura de um .phpt

Arquivos de teste seguem uma estrutura bem simples:

--TEST--
strtr() function - basic test for strstr()
--FILE--
/* Do not change this test it is a README.TESTING example. */
$trans = array("hello"=>"hi", "hi"=>"hello", "a"=>"A", "world"=>"planet");
var_dump(strtr("# hi all, I said hello world! #", $trans));
?>
--EXPECT--
string(32) "# hello All, I sAid hi planet! #"

Como vemos, a sessão TEST é um título de uma linha do teste descrito no arquivo. A sessão FILE é usada como o corpo de um arquivo .php que será gerado para o teste, e a sessão EXPECT demonstra o resultado que esperamos da execução da função. Recomenda-se o uso de var_dump para gerar saídas.

Estas são sessões padrões, mas a documentação completa pode ser vista aqui: phpt format

Você poderá ver situações onde os blocos acima não são o bastante, mas em geral você estará checando para ver se executando a função X irá retornar a saída esperada. Porem um bloco é interessante ser mencionado aqui, o bloco CREDIT. Caso você não tenha acesso ao CVS, colocando seu nome nesse bloco irá levar seu nome aos créditos do PHP, no caso do TestFest utilizamos este formato:

--CREDIT--
Rafael Dohms <myemail@gmail.com> #PHPSPTestFest 2009-04-DD

Ok. Vamos tentar escrever um teste agora para ver se entendemos tudo até agora. Usando o exemplo acima onde identificamos uma linha não coberta por testes, vamos escrever um teste para testar o primeiro parâmetro da função. Observe a linha abaixo:

zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rllll", &IM, &red, &green, &blue, &alpha)

O que devemos entender aqui é o trecho que diz “rllll” pois ele identifica o tipo que cada parâmetro deve ter, neste caso o primeiro parâmetro deve ser um “Resource” por isso o “r”, e os outros devem ser do tipo “long”. Pare um momento agora e verifique o manual do PHP para esta função

int imagecolorallocatealpha ( resource $image , int $red , int $green , int $blue , int $alpha )

Ele confirma exatamente o que vemos no código, mas você poderia também achar uma situação onde o manual esta incorreto, mais um ponto onde você poderia contribuir com o PHP.

Voltando ao nosso exemplo, vamos então escrever um teste para testar a validação do primeiro parâmetro da função. Verificando a pasta /ext/gd/tests vemos que não há testes desta função, mas especificamente não há um teste chamado imagecolorallocatealpha_error1.phpt, então como vamos testar justamente isto, podemos usar esse nome. (podemos usar _error2… para os outros parametros por exemplo)

--TEST--
Testing imagecolorallocatealpha(): Wrong types for parameter 1
--CREDITS--
Rafael Dohms <rdohms [at] gmail [dot] com>

Primeiramente vamos definir o título, deixando claro que estamos testando o parâmetro 1 da função e adicionar nosso crédito, que também é importante se houver algum erro no teste ou adaptação e precisarem saber quem foi o autor original do mesmo.

--SKIPIF--
<?php
if (!extension_loaded("gd")) die("skip GD not present");
?>

O bloco –SKIPIF– é muito importante neste caso. Como estamos testando uma função da GD, que é uma extensão do PHP, ela não estará sempre ativada, portanto só devemos executar os testes caso a extensão esteja ativa. O bloco SKIPIF é exatamente para isso, faça as verificações necessárias, caso não deva rodar, execute um die. O processo que executa os testes interpreta isso como SKIP e não FAIL. Isto vale para outras condições também, como arquivos necessários e qualquer outro fator que possa determinar se um teste deve ou não ser “pulado”.

--FILE--
<?php
$resource = tmpfile();

imagecolorallocatealpha($resource, 255, 255, 255, 50);
imagecolorallocatealpha('string', 255, 255, 255, 50);
imagecolorallocatealpha(array(), 255, 255, 255, 50);
imagecolorallocatealpha(null, 255, 255, 255, 50);
?>

Este é o corpo do teste, a parte mais importante. Basicamente estamos executando a chamada à função com diversos parâmetros inválidos, como strings, arrays e um resource que não é uma imagem. Passando um resource que não é imagem estamos na verdade testando a linha 1859, mas é uma condição importante de se testar também. O restante dos parâmetros recebem valores válidos.

--EXPECTF--
Warning: imagecolorallocatealpha(): supplied resource is not a valid Image resource in %s on line %d

Warning: imagecolorallocatealpha() expects parameter 1 to be resource, %s given in %s on line %d

Warning: imagecolorallocatealpha() expects parameter 1 to be resource, array given in %s on line %d

Warning: imagecolorallocatealpha() expects parameter 1 to be resource, null given in %s on line %d

Finalmente vamos testar o resultado. Aqui no caso utilizamos o EXPECTF que funciona como um printf, poderíamos ter usado outros disponíveis com expressões regulares por exemplo, mas o funcionamento deste é bem mais simples. Aqui basicamente estamos conferindo se o texto de erro bate com o que esperamos e como usamos um formato de printf $s e %d substituem textos que são dinâmicos, como o nome do arquivo que varia em cada máquina.

Dica: Para obter as mensagens de erro, rode o arquivos usando o PHP, ex: php imagecolorallocatealpha_error1.phpt. O arquivo será executado, todo conteudo dele será echoado na tela, mas dentro do bloco –FILE– o conteudo que aparecer é o resultado da execução.

4. Rodando um teste e fazendo faxina

Agora você tem um arquivo phpt pronto e precisamos ver se este teste esta mesmo passando. Para isso precisamos chamar o executor de testes e passar o nosso teste, caso contrário ele irá executar todos os 900+ testes. Para fazer isso o processo é simples, execute o comando make test da mesma forma de antes, mas definindo o parâmetro TESTS, assim:

make test TESTS=ext/gd/tests/imagecolorallocatealpha_*.phpt

Você pode dar o caminho completo para o arquivo, ou usar um wildcard como assim, isso é útil se você acabou de escrever os testes para todos parâmetros e quer rodar todos testes daquela função.

Veja o resultado:

Note que o teste passou, como indica o PASS logo em frente ao que escrevemos no bloco –TEST–.  É interessante também comentar o que acontece quando um teste falha, além de ser marcado com um FAIL o sistema gera um numero de arquivos com o mesmo nome e diferentes extensões:

• .out – output do arquivo php criado po teste
• .php – o código gerado para o teste (bloco –FILE–)
• .diff – uma comparacao do que foi o output e do que se esperava
• .exp – o texto em –EXPECTEDF– isaolado
• .log – um resumo do processo

Estes arquivos são muito uteis para que se analise o resultado e poque da falha.

5. Enviado seu teste para o PHP

Você possui algumas formas de fazer seu teste chegar no PHP. A primeira é participando do PHPTestFest anual, onde todos os testes são enviados para um repositório separado e então integrados ao SVN oficial. A segunda forma é você enviar este teste que escreveu para a lista do QA Team e alguem irá colocar ele no SVN por você. A terceira forma é uma junção de ambas, muitas pessoas apos a testfest são presenteadas com contas do SVN e karma para poderem comitar seus próprios testes, como ocorreu comigo (viu, não é mentira!)

Conclusão

Pronto, agora você tem todas as ferramentas para começar a escreve testes para o PHP. O PHPT é excelente para sua função em testes do PHP, mas testes não param por ai, procure incluir os testes em seus sistemas e bibliotecas, mas para isso procure o PHPUnit e aprende sobre Test Driven Development (TDD). Em breve falarei destes por aqui também.

PHP, phpt, tdd, testfest

PHP, tek09

O primeiro dia em Chicago começou cedo, as 5h. Do aeroporto pro hotel foi uma viagem tranquila, após ligar para o excelente supporte da MTACon que prontamente me apontou pro transporte do hotel, sim.. o aeroporto é enorme! Checkin sem problemas, internet fácil e dencente (fail no form, letras brancas/fundo branco), um banho e pé na estrada. Mas não antes de esbarrar com grandes nomes na porta do hotel, como Derick Rethans, Andrei Zmieski, Sara Golemon e mais uma meia duzia, a caminho da Microsoft, que cedeu uma sala para uma reunião interna do PHP (go Gates!). O resto da tarde foi o que é toda viagem de um brasileiro para os EUA… cara! Muitas compras, mas faz parte. No retorno desci para o lobby onde pude conversar com muitas figuras, dentre elas Eli White, Keith Casey, Gregg, Sebastian, enfim, muitos. Após muita conversa vem, conversa vai o papo seguiu para o Shoeless Joe’s, ou era Shirtess Schmoe’s? Enfim, janta regada a muita cerveja e mais “celebridades”, como Ben Ramsey, Elizabeth Smith, Michalangelo Van Dam, e diversos. Por sinal, FAILS stickers brotavam de todo lado, sem dúvida a culpa é do Spoons. Chegada no hotel ainda me surpreendeu com um encontro com Lorna Jane, Chris Jones .. são muitos nomes. Dentre todas estas conversas destaco uma com o Gregg sobre tecnologias e projetos de geolocation. Um execlente papo com o Michelangelo sobre comunidades e o que anda acontecendo pela Bélgica, esse papo merece mais atenção em breve. E um papo legal sobre conferencias e o que o Brasil tem a oferecer neste campo com o grupo de volta no hotel. Dia pré-evento foi um sucesso, muitos contatos e amigos. O primeiro dia de conferência amanha promete.

PHP, tek09

Este ano estarei presente na php|tek, conferencia de PHP muito famosa que ocorre em Chicago nos Estados Unidos. A conferencia é organizada pela MTA, mesma empresa responsável pela PHP|architect renomada revista impressa e digital de PHP. Fique atento ao meu twitter e neste blog (ou no blog em inglês) pois estarei postando novidades nele ao longo da viagem, que vai ocorrer de 18/05 a 22/05.

Desde que me mudei para São Paulo minha participação na comunidade PHP em geral esta cada vez mais emocionante. Desde que conversei com alguns amigos e decidimos organizar o PHPSP (Grupo de Desenvolvedores PHP de São Paulo) as ídeias não param de surgir, e muitas ideias já estão virando fatos concretos. A algum tempo venho ouvindo ótimos podcasts, tudo começou com o Nerdcast que tras um pouco de diversão ao meu dia toda manha no trem. Logo me vi procurando algo relacionado ao PHP e acabei esbarrando em dois podcasts, o PHP Abstract realizado por Cal Evans e o P3 da equipe do php|architect. Este projetos eram otimos e renderam alguns bons episódios e descobertas. Porém, perto do final de 2008 todos sumiram, sendo que o último P3 foi gravado ao redor de uma mesa em um evento descontraido de PHP, gerando um excelente episódio com o mesmo ambiente de descontração. Continuei alimentando minha fome de podcasts ouvindo o Nerdcast, que para quem não conhece é um bate papo divertido entre amigos sobre diversos assuntos, algo muito próximo de um papo de mesa de bar. Este clima de mesa de bar rende momentos excelentes, muita risada e ao mesmo tempo uma absorção de conhecimento enorme, como dizem, você aprende sem perceber. Por algum tempo pensei que o PHP precisava de um podcast, e após ouvir meu colega Luciano do site “A Sala” gravar o primeiro podcast junto com amigos (CineCast), a idéia estalou. Por que não unir a diversão do Nerdcast com meu ganha pão, o PHP? Foi exatamente isso que fizemos. Conversei com os coordenadores do PHPSP, respectivamente, O Augusto, Anderson e Ivan, e decidimos que a idaia tinha tudo para dar certo. Nem duas semanas depois do espório da ideia, já estavamos testando nossos softwares gravando o primeiro episódio. No momento da gravação este seria apenas um “teste de microfones” mas a facilidade que encontramos em começar a falar sobre o assunto nos levou a seguir em frente. Variando entre uma apresentação da iniciativa, falando sobre o PHPSP e apresentando projetos relacionados, como o PHPBC,  o podcast foi um excelente primeiro passo. Após a gravação possamos pela primeira grande dificuldade, a edição. Sem nenhuma pessoa com experiência em edição e audio em geral tivemos que nos virar com vinhetas e musicas, mas a experiencia foi muito divertida e o resultado final muito satisfatório. Assim nasceu o PHPSPCast, que você pode ouvir aqui, especificamente o primeiro episódio. A recepção foi incrível com diversas mensagens de apoio e incentivo, além de centenas de downloads em poucos dias. Este resultado só que dizer uma coisa, acertamos e devemos seguir em frente. O PHPSPCast #1 já esta sendo gravado, desta vez eu não estarei participando, pois estou atualmente na África do Sul a trabalho e sem uma conexão de internet decente o bastante para podermos gravar o cast, sem contar o fusu horário que me faria gravar no meio da madrugada. Este episódio será coordenado pelo Augusto e contará com dois convidados então fiquem de olho no resultado e aguarde novos episódios. Visite o site do PHPSPCast e descubra como enviar sugestões de assuntos, feedback e você poderá inclusive ter seu email lido no proximo episódio. Espero que gotem do resultado e que possamos trazer mais informações para a comunidade PHP com este cast, 0 primeiro podcast de PHP na lingua portuguesa.

PHP, phpsp, phpspcast, podcast

Com o crescimento continuo da importancia do Wordpress no mundo Blogger um item está cad vez mais em destaque, os plugins para wordpress. Muitos defendem que o Wordpress já não é mais um simples sistema de blog e que pode virar muito mais, como um CMS e diversos outros usos, vejamos por exemplo o Ministério da Cultura, cujo site é feito com base no WP. O sistema, embora tenha diversas polêmicas sobre seu código, foi desenhado de forma a permitir diversos ganchos e pontos de conexão em sua API para podermos plugar nossos plugins, executando atividades nos mais diversos momentos da execução de um request, ou da exibição de um post. Algum tempo atrás me dediquei a escrever um artigo completo sobre o desenvolvimento destes plugins, que é hoje o segundo post mais acessado no meu blog. A algum tempo venho recebendo ideias e pedidos de pessoas que querem desenvolver plugins para seus blogs, eles tem um problema, inventam uma solução, mas esbarram no PHP ou no codigo fonte do WP e acabam deixando de lado. Muitas vezes já existe um plugin no repositório do WP que atende ao que é buscado, porém em alguns casos sua ideia tem um twist, uma diferença ou é simplesmente original, e nessas horas você precisa de alguma ajuda. Venho querendo pegar projetos pontuais e pequenos para fazer, já que projetos grandes acabam de vez com meu tempo livre e me ocupam por muito tempo. Portanto estou abrindo aqui um espaço para ajudar estas pessoas aqui, e estarei disponibilizando uma oportunidade para criar plugins para os outros. Esta iniciativa possui tres planos:

1. Plano Open Source: Você contribui com a ideia do plugin, eu desenvolvo ele, divulgo aqui no blog e publico no repositório do link. O código fica aberto a todos e o crédito do plugin é dividido entre você e eu.
2. Plano Pago: Você me fornece com o briefing do plugin, eu desenvolvo o plugin e lhe entrego todo o código para você usar ou divulgar como quiser. O plugin carregará apenas o seu nome nos créditos.
3. Plano Combinado: Este plano é uma mistura dos dois acima, novamente a ideia é sua, mas neste caso o código não é aberto (open source), pertencendo apenas a você, porém o crédito é novamente dividido entre você e eu. Neste caso o custo de desenvovimento é reduzido.

O preço dos plugins será feito sobe encomenda de acordo com o nivel de complexidade do mesmo e de outros fatores, e será divulgado após o contato inicial para o orçamento. Somente no caso do Plano Open Source não existe nenhum custo. Vou desenvolver os plugins dentro do tempo livre que tiver então os prazos serão negociados cuidadosamente para evitar maiores problemas. Para acompanhar todo esse serviço, estarei utilizando o Redmine, um gerenciador de projetos, por isso vejam ele aqui: DMS Systems - Gerenciador de Tarefas Usem esta página [http://dev.rafaeldohms.com.br/wiki/wp-plugins/Open-Source_Plugin_Ideas] para cadastrar suas ideias de plugins Open Source, ou este email [rafael+plugins@rafaeldohms.com.br] para pedir orçamentos de plugins nos planos Pago e Combinado Observação! É importante notar que cadastrar sua ideia não tras garantia de que seu plugin será escolhido e desenvolvido, tudo irá depender do meu tempo livre e da quantidade de plugins que apareça por ai.

PHP, plugin, Wordpress

Embora publicado em 2005, o livro “Essential PHP Security” trata de um assunto que até hoje é muito atual. Escrito por Chris Shiflett o livro trata de todos aspectos de segurança relacionados a uma aplicação em PHP, por isso ainda hoje seu conteúdo pode ser considerado atualizado e aplicável a qualquer situação do dia a dia de um desenvolvedor. O livro possui uma forma muito leve e exemplificada de expor os diversos aspectos de segurança que são tratados. Assuntos estes que são muito bem expostos e claramente separados em capítulos, tratando desde forms até includes e segurança em ambientes compartilhados. Cada tópico é analisado com detalhe e dividido internamente por formas de se burlar/atacar a falha de segurança, com isso o livro se torna também uma fácil fonte de consulta onde é possível se ir direto ao capítulo que trata do aspecto que esta sendo codado e verificar as falhas que se deve prestar atenção. Além disso, o capitulo introdutório também trata do assunto de segurança de uma forma mais geral, como técnicas de análise de risco e conceitos como “Defense in Depth” que ajudam a ver segurança como um processo bem maior que analisar um único ponto de falha da sua aplicação. Mesmo sendo de 2005 o livro trata de assuntos como XSS que no atual momento da web e seu uso de AJAX deve ser sempre analisado cuidadosamente em novos e antigos projetos. Além disso velhos amigos como “Session Hijacking” e “SQL Injection” são analisados sobre diferentes pontos de vista, alinhados a segmentos específicos de um site. Esta estrutura proporciona uma leitura relaxante e de ritmo agradável que pode ser facilmente encaixada em momentos de descontração ou nas salas de espera das ocasionais idas ao médico (pelomenos funcionou para mim). O livro merece com certeza fazer parte do histórico (ou prateleira) de qualquer desenvolvedor, pelomenos para servir como ponto de reflexão, mesmo em um novo mundo onde cada vez mais Framework aparecem internalizando todos aspectos de segurança, mas como sempre digo, nos desenvolvedores temos sempre de saber o que ocorre por trás das cortinas. Essential PHP Security A Guide to Building Secure Web Applications By Chris Shiflett October 2005 Pages: 124 ISBN 10: 0-596-00656-X | ISBN 13: 9780596006563admin

PHP, review, Segurança, shiflett