Aloha,

E lá vamos nós de novo:  depois de muitas barreiras, desanimo de fórum e até mesmo o pensamento de desistência, é com prazer que a venho confirmar a realização do II Workshop PHP-ES.

O evento acontecerá no dia 28 de agosto (último sábado) na UVV, das 8:30 às 18:00 e  será gratuito: estamos tentando alguns patrocínios para bancar um Coffee break básico mas até segunda ordem vai ser tudo o mais básico possível.

A grade confirma é:

PHPZeiro: Adote um Framework (Léo Hackin)

CodeIgniter: turbinando a produtividade com MVC (Francisco Souza e André Tagliati)

MySQL: Técnicas simples e eficazes para tirar o máximo do seu servidor Mysql (Marcelo Raposo)

PHP Data Object – Interface única de comunicação com SGDBs (Almir “M3nd3s”)

Moodle: fazendo EAD de qualidade com PHP (Lucas Coradini)

Aprendendo a começar um projeto com SCRUM (Time da Giran)

Como sempre, a idéia dos eventos de PHP-ES é agregar conhecimento aos desenvolvedores PHP não só da linguagem mas também em todo o seu entorno. Nesta edição vamos mostrar como as frameworks, como o CodeIgniter e o PDO, podem ajudar na produção de aplicativos de modo mais sustentável. Falando em base de dados, teremos uma palestra de “tunning” e macetes para fazer um ajuste fino do MySQL que foram feitas em cima de uma base de verdade com o DBA dela.

Vamos exibir também um case real e de sucesso feito com o Moodle, uma ferramenta PHP de Ensino a Distancia (EAD). No final do dia teremos um workshop de como iniciar um projeto com Scrum, metodologia ágil que está sendo bastante utilizada em várias empresas de desenvolvimento pela sua flexibilidade.

As inscrições pode ser feitas pelo link no página press-release do evento:

http://www.phpes.org/ii-workshop-php-es/

Estamos ainda à procura de patrocionadores e apoiadores: se estiver interessado ou conheça alguém afim de bancar o coffee break, peça para mandar um e-mail para leohackin@gmail.com ou m3nd3s@gmail.com.

Para mais informações acesse: http://www.phpes.org/ii-workshop-php-es/

Um abraço forte e até lá.

É notável a quantidade de aplicações em PHP que ainda utilizam nosso velho e conhecido modo Macarrônico de programar: dezenas de snippets e blocos de código que trabalham com regras de negócio, apresentação e tudo mais espalhados por N lugares na aplicação.

O PHP Macarrônico é assim

Esse método é justificável dentro da PHP até certo ponto: a própria linguagem tem por princípio a simplicidade e velocidade na codificação e resolução de problemas. O próprio Rasmus Lerdorf, criador do PHP, já se mostrou bem contrário aos frameworks atuais pois eles são lentos e não escaláveis, culpa do feeling de  ”faz-tudo” que a maioria delas leva no sentido de continuar ostentando a bandeira de “desenvolvimento rápido” da PHP, que muita gente confunde com gambiarras e que transformou a PHP em sinônimo de POG (Programação Orientada à Gambiarras).

Por muito tempo eu, como muitos desenvolvedores/empresas que conheço e já conversei, pensava assim:

“Porque vou abandonar toda aquela minha infra-estrutura pronta de gerenciamento de conteúdo e minhas bibliotecas caseiras que funcionam muito bem para adotar uma framework MVC e perder $$tempo$$ precioso ou impactar no $$prazo$$ que dei para o meu cliente. Não tem porque eu correr esse ri$co“.

Existem duas situações muito especiais que consigo identificar na hora de desenvolver uma aplicação e que impactam de forma crítica na decisão correta da arquitetura a ser seguida: necessidade de escalar a aplicação e potencial expansão de funcionalidades durante e depois do projeto.

Quantas aplicações de alta consumo de banda você já desenvolveu em sua empresa com PHP ? E dessas, quantas você realmente tem que dar uma atenção e implementação contínua de funcionalidades novas ? Se você não contou nenhuma, o seu caso é bem comparável ao de muitos desenvolvedores PHP por aí. Se você contou alguma e não teve dores de cabeça com a manutenção ou testes em sua aplicação, você é um cara de sorte.

O feijão com arroz do desenvolvimento PHP no Brasil é muito atrelado à gerenciadores de conteúdo, front-end de websites e muitos projetos que geralmente são desenvolvidos por times por vezes multi-disciplinares. Um ecossistema comum são agências digitais, bureau de mídias digitais e várias outras que precisam desenvolver da forma mais simples e eficaz possível, muitas vezes devido até ao orçamento apertado e a menor margem de chance de que as coisas deêm errado para não ferrar um cronograma geralmente apertado e sem vez para os mais lentos. Juntamos isso à realidade dessas empresas que nem sempre tem um desenvolvedor com uma boa experiência, sem background de programação ou “migrados” de outras áreas e a lenha está feita.

Mesmo em ambientes mais profissionais, ainda existem aqueles que ainda resistem à idéia e são os “super-homens” que desenvolvem coisas que só eles conhecem e são difíceis de disseminar conhecimento válido na equipe.

Dentro desse contexto, algumas situações abaixo concerteza já rolaram com você ou na empresa em que você trabalha:

• Designers sobrescrevendo páginas com lógica de negócio embutida
• Programadores detonando CSS dos outros
• Classes das regras de negócio sendo alteradas a torto e direito ferrando algo que ja estava funcionando
• Métodos espalhados pela aplicação com nomes bizarros e/ou funcionalidades redundantes ou no mínimo estranhas
• Lógica de negócio repetidas, implementadas de formas diferentes e sem um lugar comum
• Registros no banco de dados com dados incompletos e inconsistentes
• Formulários que não validam tudo o que deveriam validar e que deixam cadastrar assim mesmo
• e por ai vai ….

Puxadin ali, patchzin aqui e geralmente temos monstros burocráticos ou incontroláveis que temos que lidar com o passar do tempo: fruto de uma arquitetura por vezes equivocada mas que por N motivos não pode ser substituída. E aí José ?

Adote um framework!

A solução mais sustentável para esse tipo de situação seja provavelmente a adoção de um framework, mas existe uma resistência muito grande que é completamente justificável: voltamos àquelas perguntas relativas à “para que mexer num time que está ganhando?“.

A resposta é:  ”Você pode ganhar muito mais a curto prazo e com mais qualidade de vida”.

Algumas perguntas e afirmações que já ouvi (e eu mesmo me fiz) antes de tudo:

• Meus programadores (ou eu) tem nível técnico para trabalhar com isso?
• E tudo o que eu tenho? O que eu faço que isso ?
• Isso vai atrasar o projeto cara!
• MVC ? ORM? Que p*rra é essa ?
• As funções dos meus includes já fazem tudo isso e muito melhor!
• Bah! Já temos nosso ADM pronto: é só copiar, colar e alterar os campos.
• O cliente disse que quer apenas produtos e não vai precisar de nada mais.

Todo esse tipo de pensamento/sentimento as vezes não vem de comodismo ou preguiça, mas da falta de conhecimento ou estudo de como uma framework pode ajudar no trabalho, até onde ela pode ir e principalmente em equipe multi-disciplinares com prazos ultra-curtos.

Então, vão algumas observações/pontos de vista em relação às principais frameworks PHP do mercado que podem resumir de certa forma alguns pontos positivos e relevantes para a adoção de uma framework:

• Elas já estão bem difundidas, com boa documentação e geralmente tem uma curva de aprendizado mínima: com um mês um programador iniciante estará fazendo cadastros simples e bacanas;
• Por serem frameworks de conhecimento público, a disseminação do conhecimento e uso é muito maior e não fica atrelado à uma ou duas pessoas;
• Você não tem apenas uma ou duas pessoas pra fazer “aquela melhoria no envio de e-mail”: você terá uma comunidade para te ajudar com isso;
• Se o “dono da framework” morrer, você não perder todo o investimento na ferramenta porque não existe “dono”. Acaba aquela falácia do “super-homem” ou do “cara que fez a framework e só ele sabe mexer nisso”.
• Estatisticamente comprovado, desenvolver e manter uma framework caseira é muito mais custoso que usar e customizar uma framework já extensamente utilizada no mercado, tanto à nivel de suporte quanto à melhoria da ferramenta e correção de bugs;
• O que traz diferencial para o negócio de seu cliente (e o seu) é o conhecimento de negócio: a ferramenta será apenas um meio e é mais que bacana que ela esteja pronta e você se preocupe apenas com o negócio e não como “fazer aquele usuário logar e se manter autenticado em página X e Y”.
• Frameworks trabalham com padrões de design testados e refatorados continuamente por pessoas com anos de experiência em software: é jogar dinheiro no lixo tentar re-inventar a roda ou re-implementar tudo se não for completamente necessário.
• Programadores experientes terão uma ferramenta amplamente testada e na maioria das vezes bem flexíveis quando precisar adaptar “aquela regra de negócio extraterrestre do cliente XPTO“;
• Frameworks tem um conjunto grande de plugins/componentes que cobre a maior parte das tarefas comuns como controle de sessão/cookies, envio de e-mails, upload de imagens, internacionalização, autenticação e por ai vai. Se não existir, geralmente é fácil (e muito didático) desenvolver algo novo e que a comunidade vai concerteza agradecer;
• A parte de visualização dos dados (view) fica separada do controle das ações possíveis no sistema (controller), que por sua vez tem que respeitar as regras de negócio implementadas no acesso ao banco (model) que ficam centralizadas num lugar apenas: ou seja, o MVC (Model-View-Controller) vai diminuir bastante o quebra pau entre designers e programadores e evitar bastante re-trabalho. No caso de sistemas, vai melhorar e muito a manutenção deste;
• O trabalho com testes é praticamente embutido nessas frameworks e é uma forma ótima para iniciar os trabalhos com TDD nos projetos. Testes não são moda e sim uma tendência natural do mercado onde as aplicações precisam ser cada vez mais confiáveis para não trazer prejuízo para seu cliente;

Boa parte das dúvidas que geralmente se tem recaem principalmente na preocupação de comprometer um projeto com questões técnicas e impedimentos ou na parte do aprendizado em si da ferramenta. Felizmente, com o tempo se percebe que com empenho em cerca de um ou dois meses uma boa framework é absorvida naturalmente.

De certa forma, ela até mesmo promove uma auto-reciclagem de todos os profissionais pois começam a envolver questões como padrões de projeto, orientação à objetos, testes, controles de versão e tudo o que há mais de novo no mundo de desenvolvimento e que volta e meia não chega ao mundo das agências ou software houses mais caseiras.

Em resumo

A adoção de uma framework MVC não é um bixo de 15 cabeças cuspindo fogo e destruindo, mas assim como qualquer novidade apresenta riscos e custo, que CONCERTEZA são altamente recompensadores mesmo que no final ela não seja aproveitada: idéias são concebidas e o nível de conhecimento pós-experimentação é notadamente maior.

Para quem quiser tentar, algumas dicas podem ajudar (ao menos me ajudaram):

• Inicie com projetos pequenos ou internos para sentir como a framework funciona e até mesmo descobrir características a favor ou contra sua adoção na empresa. Após conhecer pontos fortes e fracos, decida se ela é realmente viável em seu projeto;
• Se você tem um time, escolha uma pessoa para estudar a ferramenta escolhida e depois faça um hands-on com a equipe pois assim as dúvidas/conclusões fluem de uma maneira surpreendente;
• Procure conhecer sobre OO (Orientação à Objetos), ORM (Object-Relational Mapping), MVC (paradigma Model-View-Controller), TDD (uso bastante o SimpleTest), controle de versão (estamos usando bastante o GIT) e metodologias ágeis (uso bastante o Scrum): essas coisas “puxam” junto um monte de outras coisas que vão fazer o aproveitamento de qualquer framework MUITO maior;
• Participe ativamente de listas para tirar dúvidas suas e dos outros: em pouco tempo se tornar um commiter em um projeto pode ser uma experiência e tanto de aprendizado;
• Mantenha-se antenado nas novidades da framework: a maioria delas tem atualizações constantes e as vezes até chave para alguma coisas que sua empresa pretende fazer;

Existem, claro, frameworks com diferentes abordagens e  vantagens. Então, para tentar encurtar o caminho mas sem traçar um comparativo muito técnico, vão algumas bacanas para se começar:

• CakePHP, hoje uma das frameworks mais conhecidas e utilizadas no PHP, é uma ferramenta bem influenciada pelo Ruby On Rails, com documentação bacana e uma comunidade grande pacas. Sua curva de aprendizado é bem fácil e os resultados saem bem rápido também, devido ao enorme número de coisas prontas para serem utilizadas. Um ponto fraco é sua performance que não é tão rapida quanto às concorrentes;
• CodeIgniter, é uma framework que vai no caminho contrário da CakePHP: ela é mais enxuta e sem muitos componentes para rodar bem rápido. Sua curva é tranquila e a documentação bem bacana. Um ponto fraco é a ausência nativa de ORM para mapeamento do banco de dados.

Existem várias frameworks, com vários “sabores” a serem degustados: é ver, testar e ver qual mais agrada e ser feliz!

Simbora.

Olá pessoal,

Continuando nossa sequência de artigos sobre o SimpleTest, já aprendemos como fazer testes unitários e agrupa-los para facilitar a execução em lote: agora vamos falar um pouco sobre mock objects.

Até agora, nossos testes unitários se resumiram a testar métodos e funcionalidades que envolviam apenas uma classe como nossa calculadora: tínhamos um método chamado “somar” que fazia parte da própria classe e recebia como parametro de entrada apenas dois inteiros.

A idéia do teste unitário (ou de unidade), como o próprio nome diz, é isolar e testar apenas aquele ponto e funcionalidade do software: então é imprescindível que possamos isolar da melhor maneira apenas a classe/métodos que desejamos testar para que, caso apresente falha, possamos identificar exatamente onde a falha ocorreu.

Mas e quando nossa classe depende de outra(s) classe(s) para fazer um método funcionar ?

Conceituando o problema

Então, vamos imaginar a seguinte situação: estamos desenvolvendo um software de e-commerce e em dado momento precisamos validar se um usuário existe em nosso banco de dados. Apesar das possibilidades abrangentes de um sistema de validação/autenticação, vamos nos preocupar com o básico e implementá-lo de uma forma simples como abaixo:

As classes usadas no validador

Vamos criar uma classe chamada Validator, que receberá o login do usuário, verificará no banco de dados se ele existe ou não e validará seu acesso. Para tanto, nossa classe de validação terá um método chamado validate, que receberá um parâmetro string representando o nome do usuário a ser validado.

Para conectar-se ao banco de dados, nossa classe receberá em sua criação um objeto referente à classe Conexao, que disponibilizará um método chamado query, que consulta o banco e retorna uma array de resultados.

classe validator.php

classe conexao.php

Para que tudo fique mais claro, podemos dar uma olhada em como ficaria nosso código final da aplicação:

Como aprendemos em nosso primeiro artigo sobre TDD, primeiro fazemos os testes e depois fazemos nossa aplicação passar nos neles, implementando a lógica de negócio válida. Nosso objetivo nesse momento é testar o método validate: fazendo um pouco de nossa flexão mental chegamos a dois comportamentos válidos para o método:

• Se o usuário existir, ele retornará true;
• Se o usuário não existir, ele retornará false;

O problema

Então, pensamos “Bacana! Então vou fazer um caso de teste chamado ValidatorTestCase e um teste chamado testValidarSeUsuarioExistir que irá validar se um usuário foi validado se ele existir!“.

Partimos para o código então:

Tudo ok ? NADA OK! O código acima pode funcionar mas temos alguns problemas:

• Como garantir que nosso banco de dados vai estar disponível na hora do teste ?
• Como vamos saber se existe o usuário que queremos testar está no banco, para testarmos se a validação realmente vai passar no teste e se comportar como queremos ?
• E se ocorrer um erro de conexão ao banco no meio do teste ?
• E se a conexão banco for demorada e nosso caso de teste ter 50 testes acessando o banco? oO
• Como saber se as configurações estão exatas para a conexão no banco? Aliás, eu nem sei nada sobre config até agora!
• E principalmente: e se ocorrer um problema na pesquisa da query que não tenha nada haver exatamente com nosso validador, já que nosso objetivo é testar unicamente se “ao receber um usuário, verificar se ele existe no banco e validar em caso afirmativo”.

Haja coisa né ?

Mock Objects (nosso boneco de testes)

Pensando nesse problema, foram criados os Mock objects. Um mock object (vou usar o termo em inglês pois a esmagadora maioria das referências TDD estão assim) nada mais é que um objeto que simula e imita o comportamento de um objeto real.

Imagine os bonecos de teste de batidas de carro: os engenheiros os constroem com peso, altura, juntas e vários aspectos que imitam o corpo de um ser humano para poderem fazer seus testes. Eles colocam esses bonecos nas mais variadas situações e posições possíveis para testarem a segurança de um carro entre outras coisas, sem precisar matar ninguém para isso.

No nosso caso, nossos mock objects são representações de classes reais onde podemos simular e forçar qualquer comportamento que desejamos para testarmos certas situações que talvez não seriam possíveis de serem alcançadas “explicitamente” sem gambiarra-las ou mesmo que sejam de dificil configuração.

Em resumo, usamos um mock quando nossa classe real (colado do wikipedia – thank’s god):

• gera resultados não deterministicos (e.g. a hora ou temperatura atual);
• tem estados que são difíceis de criar ou reproduzir (e.g. erro de comunicação da rede);
• é lento (e.g. um banco de dados completo que precisa ser inicializado antes do teste);
• ainda não existe ou pode ter comportamento alterado;
• teriam que adicionar informações e métodos exclusivamente para os testes (e não para sua função real).

Analisando nosso problema anterior, podemos constatar que nossa classe Conexao é forte candidata à ser “mockeada”: assim nos livramos de todos aqueles problemas de conexão, de existência de registros e tudo mais que não tem nada haver com nosso teste unitário em si, que diz respeito pura e diretamente à nossa classe Validator.

Ou seja, ao invés de usar a classe Conexao real, vamos usar uma “imitação” dela, muito mais simples e fácil de manipular para chegarmos de forma mais simples ao nosso resultado esperado no teste unitário. Vamos utilizar esse mock pois não faz sentido testar a conexão nem nenhum método dessa classe e sim utilizar o comportamento referente ao código que vamos utilizar no nosso teste.

Codando!

Como vimos, nossa classe Conexao não tem nada implementado ainda. Mas isso não nos interessa pois vamos fazer um mock da classe, para podermos simular o que precisamos: o retorno dos resultados que desejamos para testar o método validate do Validator.

Para criar um mock de nossa classe, simplesmente fazemos o include dessa classe em nosso teste e “geramos” esse mock com o método generate da classe Mock (que é importada automaticamente no nosso include do autorun.php do Simpletest).

Com isso, vamos gerar um clone mockeado da classe Conexao para podermos usa-la em nossos testes.

Fácil né ?

Mocks como atores

Agora que sabemos como criar um mock, vamos aprender a “imitar” o que a classe original faz afim de “simular” os resultados que queremos ter para fazer nossos testes passarem.

Os Mocks podem se comportar de duas maneiras:

• como Atores (Actors), onde o Mock é usado para simular o retorno de propriedades e métodos (e o que vamos usar aqui).
• como Críticos (Critics), onde o Mock é usado para guardar e verificar as interações entre os objetos num teste.

Quando trabalhamos com o Mock apenas como Ator, apenas simulando o retorno de propriedades e métodos, ele é considerado um “server stub”, que nada mais é que um objeto que simula um comportamento. Existe uma grande discussão existe em torno disso, mas por enquanto vamos deixar pra lá pois vamos falar sobre os Mocks como uma ferramenta para testes baseados em interação no próximo post e isso vai ficar mais claro.

Se analisarmos a classe Conexao novamente, vamos chegar à conclusão que o método que vai ser utilizado em nosso teste será apenas o query: vamos fazer uma consulta à base dados buscando todos os usuários cujo nome seja igual ao parametro que enviarmos ao método validate.

Nosso mock da Conexao ainda não sabe fazer nada, mas podemos instrui-lo a retornar o que a quisermos. Por exemplo, em nosso teste chamado testValidarSeUsuarioExistir vamos ter que dizer ao mock para retornar sempre um resultado que satisfaça nosso teste. Ou seja, como no exemplo da implementação, se eu envio “Léo” ele tem que me devolver um resultado onde “Léo” esteja presente, pois queremos testar o comportamento do validate e não o retorno de valor da conexão.

Então, vamos fazer nosso mock devolver sempre um resultado onde exista o usuário “Léo” no resultado.

Como vimos, nosso método query retorna uma array com os resultados da consulta. Vamos então instruir o mock a retornar sempre um array quando o método query for chamado. Quando o objeto é mockeado, ele ganha vários métodos, entre eles o setReturnValue: esse método diz ao mock “retorne sempre X resultado quando tal método for chamado”.

Pronto! Agora podemos testar nosso validate:

O que aconteceu em nosso teste:

• Criamos um mock do nossa classe Conexao
• Instanciamos esse mock em nosso teste
• Instruimos ao mock para que ele devolvesse sempre um array com o usuário Léo quando o método query fosse chamado
• Instanciamos nosso validator, passando como parâmetro nossa conexao mockeada
• fizemos o teste para verificar se a validação deu certo

Fui roda-lo e ….

Opsss! Falhou!

Temos nosso resultado esperado, afinal não implementamos ainda nosso método validate. Então, vamos resolver isso:

Implementamos uma lógica onde fazemos uma pesquisa ao banco pedindo para selecionar o id e o nome da tabela users onde o nome seja igual ao parâmetro enviado. A mágica acontece finalmente: nossa ” falsa conexao” foi instruída a retornar sempre um array com uma posição apenas, onde o resultado sempre é Léo.

Agora quando rodamos o teste:

Teste do validator agora com a implementação

Bingo! Nosso teste passou!

Para comprovarmos que o funcionamento do validate está correto, vamos complementar nosso caso de teste adicionando um teste pra verificar se informarmos um usuário que não existe, ele retornar false.

Vamos testar denovo e …

Fazendo dois testes

Mantemos o nosso mock retornando apenas “Léo” nos resultados, mas dessa vez passamos o nome “Jeveaux” para procurar e como esperado, ele retornou false, dado que o usuário “Jeveaux” não existe. Show!

Ufa! Vamos resumir o testamento

O aprendizado de mock objects é um pouco abstrato inicialmente mas com alguma prática se revela uma técnica perfeita e viável para fazemos nossos testes unitários funcionarem de forma correta e independente. A utilização do Mock Object apenas como ator (ou server stub como você lerá muito por ai) é apenas uma parte do poder real de um mock.

Dentro de nosso entendimento, podemos resumir que um mock object é uma imitação de nosso objeto real que podemos manipular de forma fácil e simples para que ele faça exatamente o que quisermos, facilitando assim a implementação de nossos testes unitários e isolando nossas classes.

Algumas leituras legais melhorar o entendimento dos Mock Objects:

• Mock Objects no SimpleTest [ doc oficial do SimpleTest ]
• Testes de unidade com mock objects [ ImproveIt ]
• Mock Objects and Stubs: The Bottle Brush of TDD
• Mock Objects [ Wikipedia]

Outra referência bem bacana é o blog do Jeveaux, meu revisor TDD oficial e grande conhecer de causa.

No próximo post vamos ver como trabalhar com nosso Mock Object em sua forma mais plena e com um exemplo um pouco mais complexo para partir também para o modo Critic.

Simbora.

Para quem já está mexendo com CakePHP a algum tempo, algumas limitações de funcionalidades podem tirar um pouco o sono de quem está muito mal acostumado com a produtividade da framework. Em geral, toda framework tem seus pontos fracos.

A algum tempo, tive um problema curioso: a chave primária de uma tabela teria valores alfanuméricos. Ou seja: valores como “205-A”, “JB02″ e outros bizarros seriam possíveis. Regra de negócio definida, modificação do modelo para o nome de chave fora da convenção e tudo corria bem até que populei um select.
Qual não foi minha surpresa em ver que o CakePHP, além de não marcar o valor correto, em certos casos ainda selecionava mais de um valor no select. #fail total.

Pesquisa na internet, perguntas na lista de discussão oficial do CakePHP e as respostas eram:

• Coisas que não tinha nada haver com o problema
• Sugestões pra mudar a estratégia para resolver o problema
• Gente falando que o CakePHP só trampa com valores numérico (o que de fato acontece )

O problema

Então, mexendo no código pra cima e pra baixo (sem conotações sexuais por favor) consegui achar o problema.

No arquivo  cake/libs/views/helpers/form.php (cakephp 1.2.5), na linha 1710:

if ((!$selectedIsEmpty && $selected == $name) || ($selectedIsArray && in_array($name, $selected))) {

Depois de fuçar e testar um pouco, vi que o problema principal na verdade é um problema com o próprio operador == do PHP: ele trata as operações entre strings e numéricos (http://php.net/manual/en/language.operators.comparison.php) de uma forma que gera os seguintes resultados:

• um valor como 206-1 por exemplo, o helper casava tanto o valor 206-1 (o correto) quanto 206 (string == integer).
• um valor como JB01 por exemplo, o helper casava tanto o valor JB01 (o correto) quanto 0 (string == integer).

Devido à característica do PHP de resolver qual o tipo da variável em tempo real, ele tenta fazer o casting da variável sempre e acaba gerando resultados não esperados pra gente.

Solução

A solução então foi forçar (type casting) as variáveis para serem tratadas como strings. Assim, evitamos que o PHP transforme nossas variáveis em tipos distintos (no nosso caso string e integer) e consequentemente faça a comparação de valores do jeito que precisamos.

A linha 1710 (no cakephp 1.2.5 ou 1748 no cakephp 1.3-dev) ficou assim:

if ((!$selectedIsEmpty && (string)$selected == (string)$name) || ($selectedIsArray && in_array($name, $selected))) {

Note o type casting sendo feito nas variáveis $selected e $name.

Se alguem conseguir uma solução mais bacana ou encontrou outro bug bizarro do CakePHP, compartilhe!

Simbora!

Update: Eu tinha reportado esse erro a algum tempo no track de bugs do CakePHP  e hoje vi que já corrigiram isso. Então, quando sair a versão stable do cake 1.3, não precisa mais se preocupar com isso.

Aloha,

Primeiramente, obrigado ao pessoal pelas belas palavras de incentivo e tudo mais: é esse tipo de coisa que nos empolga pra continuar trabalhando e estudando duro.

Em nosso post de iniciação no SimpleTest, criamos um caso de teste completo de uma calculadora. Relembrando nossa telinha bonita do caso de teste…

Agora vejamos … e se por exemplo, tivéssemos não apenas uma calculadora em nossa aplicação, mas também uma agenda de compromissos, uma agenda de contatos, um wiki, um mural de recados e … enfim, se nossa aplicação fosse composta por N classes como faríamos para rodar os casos de teste unitários de TODAS AS CLASSES ?

Na TDD, como vimos antes, escrevemos todos os testes antes de começarmos a implementar nossa aplicação em si: quando pensamos “rodar os testes” isso se aplica à todas as classes e funcionalidades que possam gerar erros em nossa aplicação.

Ai você: “Rapaz, vou ter que acessar teste por teste como fiz com a calculadora? Mamãe, eu tenho 253 casos de uso!!!!”

Imagina só se você executar, URL por URL ou comando por comando, 253 casos de uso. =/

Pensando nisso, a SimpleTest disponibiliza um recurso de agrupamento de casos de teste chamado de Test Suite. Esse recurso permite agrupar vários casos de testes numa só classe, facilitando e permitindo a execução desses testes com uma só chamada.

Seria como um script de checagem, onde cada item seria um caso de teste:

Checagem do carro

1. Checar Óleo
2. Checar Rodas
3. Checar Água Carburador
4. Checar itens de segurança

A test suite funciona exatamente assim, executando cada caso de teste na ordem que você desejar: o “check list” roda e no final você tem todos as falhas que ocorreram, separadas por caso de test e método.

Codando!

Bom, vamos supor que vamos ter uma aplicação composta por 5 classes: ClasseA, ClasseB, ClasseC, ClasseD e ClasseE. Cada uma delas tem suas próprias implementações e vamos ter que fazer casos de testes que testem elas individualmente.

Para ilustrar o funcionamento, vamos escrever um método para todas as classes chamado Dizer: esse método deverá receber a uma string e retornar “Estou dizendo ” concatenado com o que você passou como parâmetro. Exemplificando

Vamos botar esse método em todas as classes apenas para simularmos as passagens e não passagens de teste delas. hehhehe

Bom, partindo do pressuposto que você esteja com o SimpleTest instalado e com nossa estrutura de arquivos do artigo de iniciação à ele, vamos escrever o caso de teste da ClasseA que será salvo dentro da nossa pasta tests e terá o nome de classe_a_test.php.

Relembrando um pouco:

• Fazemos o include do arquito autorun.php para automatizar nossos testes;
• Fazemos o include da classe que vai ser testada
• Implementamos a classe de teste iniciando por “Test” afim de que a SimpleTest execute-a automaticamente;
• Criamos o método testDizer para testar o método dizer da nossa ClasseA;
• Fazemos um assertIdentical que executará nosso método dizer passando “Muito Bacana” e esperará como resultado algo IDENTICO à “Estou dizendo Muito Bacana”;

Beleza, agora vamos rodar nosso teste …

Como era esperado (espero) nosso teste deu pau porque não escrevemos nossa ClasseA ainda em arquivo algum. Então, vamos escrevê-la e salva-la dentro da pasta classes com o nome de classe_a.php:

Agora, vamos rodar novamente nosso teste:

Massa demais! Fizemos novamente um caso de teste. Até ai nenhuma novidade.

Agora o exercício braçal: crie os casos de teste para a ClasseB. ClasseC, ClasseD e ClasseE lembrando que:

• Classes da aplicação devem ser salvas dentro da pasta classes
• Classes dos casos de teste dentro da pasta tests

Após a criação delas, faça os testes (jura?) e veja se está tudo ok.

Criando nossa suite de testes

Agora que executamos todos os testes de forma separada, vamos junta-los em nossa suite para faze-los todos de uma vez só.

Vamos criar nossa suite de testes no arquivo all_tests.php e salva-lo na pasta tests junto com todos os nosses casos de uso.

Explicando nosso script:

• fazemos o include de simpletest/autorun.php para fazer rodar nossos testes
• fazemos os includes de todas os casos de testes que usaremos na suite
• criamos uma classe AllTests que extende TestSuite, que por sua vez é a classe que será responsável pelo agrupamento e execução de todos os testes
• criamos um método AllTests que fará a execução dos casos de teste
• Nomeamos a suite de testes com o nome All tests com o método $this->TestSuite;
• Adicionamos então todos os nossos casos de teste com o método $this->addTestCase, instanciando o objeto de cada classe de teste

Agora, basta rodar:

Pronto! Nossa suite agrupou nossos testes (que eram cinco ao todo, cada um com um método de teste) e executou todos de uma vez. A lógica da suíte é você inserir os testes conforme seu contexto e sua necessidade de agrupamento de testes. Para incluir, basta repetir o procedimento já feito no arquivo da suíte:

• faça o require_once do arquivo php do caso de teste
• inclua o caso de teste com $this->addTestCase

E se algum teste falha-se ? Vamos fazer o teste da ClasseB falhar. Para isso altere a classe B para para retornar algo que não seja “Estou dizendo ” mas sim “Eu vou dizer “: com isso, nosso teste vai falhar. Após alterar a classeB, rode a suite de testes novamente:

Como pode ser visto, nossa suite de testes dá o erro exetamente onde ele aconteceu: no nosso caso, a suite de testes que chamamos de All tests reportou o erro do caso de teste TestOfClasseB no método testDizer. Maneirasso não ?

Nossa suite mostra todas as falhas por caso de teste. Simples e rápido.

E vamos às considerações

A forma que fizemos a construção da nossa suite de testes está diferente da forma em que o próprio site da SimpleTest (http://www.simpletest.org/en/start-testing.html) mostra em sua página inicial no Quick Start dele, que está diferente do link que deveria ser a mesma explicação mais detalhada, mas não é. Se olharmos o script de test suite do quick start teremos, aplicando ao nosso exemplo, teríamos:

Concerteza é um jeito mais prático: ao invés de fazer-mos os includes dos casos de testes e fazermos os instanciamentos dos mesmos no addTestCase, requerendo mais programação, simplesmente podemos incluir o teste com um addFile. E isso realmente funciona. Mas infelizmente não sem algumas adaptações no código.

Se quiser re-escrever sua suite de testes nesse formato, se atente ao fato que o SimpleTest aparentemente trabalha com a suite de testes acessando os caminhos absolutos dos arquivos e se perde quando referenciamos nossos arquivos, mesmo que eles estejam na mesma pasta tests. Para contornar isso, coloque a inclusão do arquivo de classe no caso de testes e a referência ao arquivo do caso de teste na suite com seus caminhos absolutos. Vamos isso na classeA por exemplo:

Na classe_a_test.php teríamos:

E na nossa suite all_tests.php seria re-escrita como:

Espero que tenham gostado e no próximo post falaremos um pouco sobre MockObjetcs.

Até lá.

Olá a todos,

Post rápido sobre uma novidade bacana e que me deixou bem feliz essa semana: fui convidado a ser um articulista no portal iMasters. O primeiro artigo a ser publicado lá foi o Iniciando com o SimpleTest e a idéia é ter alguns dos posts que coloco aqui sendo publicados lá.

Agradeço à equipe da iMasters pela honra e espero que possamos distribuir conteúdo legal e relevante pelos próximos tempos por ai.

Simbora!

Salve people,

Vamos iniciar hoje uma pequena jornada à terras que possivelmente muita gente só viu/leu em sites especializados e muito pouco comentadas em PHP: a terra do desenvolvimento orientado a testes, ou TDD.

Se você não sabe ou nem faz idéia do que é TDD, dê uma procura no Google pois existem dezenas de sites muito bacanas destilando idéias e tudo mais sobre isso.

Em poucas palavras, TDD (Test Driven Development) é um técnica de desenvolvimento de software que nos diz que devemos escrever os testes antes de escrever o código da aplicação propriamente dito.

Inicialmente isso parece meio louco: afinal, você sempre testa DEPOIS de escrever seus programas ou durante, enquanto debuga tudo, correto ? Mas com o passar do tempo, a verdadeira natureza e vantagem do TDD, quando aplicada corretamente, se faz presente.

Você se torna capaz de antecipar a detecção e correção de várias falhas, reduzindo dramaticamente o tempo gasto com correções em cima de implementações muito complexas já praticamente no final do seu cronograma.

Hoje em dia, existem várias frameworks que auxiliam nessa tarefa de escrever testes. O foco aqui é algo que poucos sites (principalmente em português) abordam de forma prática que é o uso da SimpleTest, uma framework para testes unitários que vem ganhando o espaço antes ocupado pelo PHPUnit.

No decorrer dos próximos posts sobre o SimpleTest, você poderá adquirir um pouco de conhecimento que poderá ser útil em seus futuros projetos. Então, vamos simbora.

Instalando o SimpleTest

A instalação do SimpleTest em si é muito fácil.

1. Baixe a versão mais atual do SimpleTest no site http://www.simpletest.org (a versão que usaremos nessa sequência de tutoriais é a 1.0.1). A framework é composta por uma pasta simples;
2. Descompacte o arquivo dentro de sua aplicação. Para fins de organização, vamos criar uma pasta “tests” na raíz de nossa aplicação e descompactar o zip/tar do SimpleTest lá: ao descompactar você verá uma pasta chamada simpletest sendo criada.

Em tese, nossa aplicação pode ter qualquer estrutura de diretórios. O SimpleTest funciona tanto com functions como com classes. Vamos abordar o uso de classes, dado que o TDD é amplamente usado em sua maioria em soluções OO (Orientadas a Objeto) e acho que já passou da hora da comunidade PHP pensar OO.

Partindo desse pressuposto, vamos criar a pasta “classes” na raíz de nossa aplicação: lá iremos botar todas as nossas classes que serão usadas nos testes.

Teremos então, uma estrutura de arquivos como abaixo:

A pasta app_tdd é a pasta onde está nossa aplicação: uma pasta criada dentro do meu htdocs (raíz do Apache).

Se o seu servidor web estiver instalado com configurações padrão, provavelmente você poderá acessar usando: http://localhost/app_tdd

Nosso problema: uma calculadora

Com o SimpleTest “instalado” em nossa aplicação e nossa estrutura de diretórios resolvida, vamos escrever nosso primeiro caso de teste.

O cenário de nossa aplicação é uma calculadora: nossa calculadora conseguirá efetuar apenas a operação de soma.

Com uma análise rápida do problema, já nos vem à cabeça que:

• Uma classe chamada “Calculadora” com um método chamado “soma”;
• Nosso método soma recebendo dois números
• Nosso método retornando o valor da soma entre os dois números

Nossa abordagem não TDD seria: vamos fazer a classe, implementar o método e depois testa-lo em uma página teste. Correto ? Num primeiro momento isso seria ótimo: afinal, o código e complexidade das classes inicialmente são lindos.

Mas imagine agora sua aplicação crescendo e crescendo: classes extendendo e usando outras classes. Você extende a Calculadora, outra classe utiliza o método soma e você vai testando apenas “o que vem depois”.

Num dado momento, você tem um resultado incorreto de soma: uma entrada incorreta de parâmetros, um deles ser uma letra e não um número, termos uma passagem de um objeto ao invés de um número propriamente dito … De quem é a culpa ? Da classe nova, que esqueceu de filtrar a entrada de parametros ? Do designer, que esqueceu de limitar a entrada dos valores no form para apenas números ? Do outro programador, que foi descuidado e não validou se os dados passados eram realmente números antes de chamar a soma ?

Enfim, temos N cenários onde a detecção do erro pode ser muito custosa, seja pelo método para encontra-lo (que varia do debug minucioso ao “achismo”) e/ou pelo custo em termos de tempo para concerta-lo. Tudo isso pode gerar um custo/prejuízo que seria reduzido com a implementação do pensando TDD.

Pensando primeiro em testes

Mentalize: “Quais as situações que podem quebrar meu método soma? Se acontecer, como devo tratar esse erro ?”

Com base nesse pensamento, podemos deduzir:

• Para somar, nossa calculadora terá que receber sempre dois números;
• A soma sempre ocorre entre dois números, nunca entre letras, objetos ou qualquer coisa que não seja exatamente um número;
• Se algo der erro, devo retornar falso;

Interessante! Não implementamos nenhuma linha de nossa solução e já sabemos:

• Que vamos precisar de uma classe (Calculadora) com um método de soma;
• Sabemos que o método deverá receber dois parâmetros que deverão ser sempre números;
• Que se for passado qualquer coisa que não sejam dois números, eu devo retornar falso;

Bom, então vamos implementar a classe ? Não, pequeno gafanhoto: vamos implementar primeiro os testes, porque é com base neles que vamos ter certeza que nossa classe se comportará exatamente como pensamos que ela deve se comportar sob os mais diversos cenários.

Escrevendo nosso primeiro teste

Implementar um teste com SimpleTest é, como o nome já diz, “simples”.

Vamos criar todos os nossos testes dentro da pasta tests. Para cada classe que tivermos que testar, vamos criar um caso de teste (unit test case) que será representado em um arquivo php.

Então, nosso primeiro caso de teste será o calculadora_test.php. O nome do arquivo não tem um padrão de nomenclatura, mas por convenção usa-se sempre nomedaclasse_test.php.

calculadora.php -> calculadora_test.php

A estrutura inicial do nosso arquivo calculadora_test.php será a seguinte:

Pronto! Nosso caso de teste da classe Calculadora está feito. Para testa-lo, vamos apontar o browser para http://localhost/app_tdd/tests/calculadora_test.php. O resultado será:

Ops! Não criamos nossa classe ainda, por isso obtemos esse erro. Quando disse que escrevemos testes antes de implementar nossa lógica, estava falando sério. =)

Vamos criar nossa classe Calculadora então.

Legal, agora vamos acessar nosso caso de teste denovo.

Uhu! Funfou!!!

Analisando o código:

• fazemos o include de dois arquivos:
  • o arquivo autorun.php é o arquivo que faz a “mágica” acontecer: é ele quem roda os testes e exibe os resultados, portanto deverá sempre estar no seu caso de teste;
  • o outro arquivo é a classe que desejamos usar no teste, no caso calculadora.php
• Criamos uma classe chamada TestOfCalculadora extendendo UnitTestCase, que será a classe que o SimpleTest usará para fazer o teste. É obrigatório que a classe inicie com o nome “test” para que o SimpleTest execute automaticamente a mesma como um caso de teste. Existe uma forma de faze-lo sem iniciar o nome com “test”, mas isso não vem ao caso agora.

Maneiro né ? Mas como puderam notar, nosso caso de teste não testa nada ainda. Hahahah

Vamos adicionar agora um teste: o teste vai verificar se a soma está realmente “somando” dois números. Para isso, devemos adicionar um método à nossa classe de testes. Vamos chamar esse teste de “testSomaDoisNumerosInteiros“, onde vamos passar dois números inteiros esperando que a soma deles esteja correta.

Usar nomes grandes assim no nome do método são uma boa prática, já que deixam os testes mais legíveis na hora de rodar o caso de teste.

Como visto, temos nosso método testSomaDoisNumerosInteiros que instancia nossa classe Calculadora e depois executa um método chamado assertEqual. Esse método é o responsável por testar nossa soma. Ele significa:

Verifique se a chamada $calculadora->soma(1,1) retornará um resultado igual à 2

Se a chamada retornar qualquer coisa diferente de dois, nosso teste irá falhar, indentificando que algo de podre está acontecendo em nosso método soma.

Se rodarmos esse script teremos enfim:

Tivemos uma falha. Traduzindo a mensagem de forma prática:

O seu teste testSomeDoisNumerosInteiros, do caso de teste TestOfCalculadora, falhou porque NULL (que foi retornado pela chamada ao nosso método soma) não é igual a 2 (que seria nossa resposta esperada).

A resposta para isso é que ainda nem implementamos nosso método soma. Mas vejamos que nesse ponto já sabemos exatamente como deve ser comportar nosso método para o funcionamento com dois números.

Vamos implementar nossa classe então:

Com nosso método agora implementado, vamos executar nosso caso de teste denovo.

Agora sim! Temos um caso de teste funcional que testa uma classe implementada. Parabéns por chegar até aqui.

Nesse ponto, já temos conhecimento suficiente para escrever vários casos de teste para nossas classes. Um caso de teste pode conter vários testes diferentes: cada teste é feito através de um método da classe do caso de teste.

Revisando aquelas possibilidades de cenário que poderiam “quebrar” nossa calculadora, já testamos se a soma está correta. Agora, podemos testar as possibilidades que podem gerar um erro na calculadora.

Uma delas é se passarmos letras no lugar de números: haviamos combinado que nessa situação, devolveriamos falso para o resultado, correto ? Então, vamos escrever o teste: vamos chama-lo de “testSomaNaoNumeros“:

Adicionamos essa função à nossa classe. Rodamos nosso teste novamente e …

Previsivelmente, temos um erro pois nosso método soma ainda não verifica se os parâmetros recebidos são números válidos. Ai você irá pensar:

Mas eu vou escrevendo os testes e vou implementando toda a minha lógica de negócio ao mesmo tempo ?

A TDD tem uma característica bacana, que anda de mãos dados ao refactoring: a TDD nos diz que devemos SIM escrever os testes primeiro e fazer as classes “passarem no teste” usando o mínimo de código possível: se a lógica for complexa, retorne uma resposta “hardcode” para “enganar” o teste e depois faça o refactory do código.

O refactory deve ser feito apenas depois de todos os testes serem feitos, pois nesse ponto você terá certeza de como o funcionamnento de sua classe atenderá a todos as respostas que são requisitadas nos testes como “corretos”.

Pensando nisso, vamos fazer nosso método soma “passar” no teste:

Agora, vamos rodar nosso teste.

Blz! Nosso teste passou, mas testamos apenas se os valores são inteiros e se forem, efetuamos a soma. Se não forem, a gente retorna false, como nosso teste pediu. Podemos depois refatorar isso: verificar se o valor é uma string com um número dentro e por ai vai.

Finalizando

Você pode estar se perguntando: “Uai, mas podemos ter muito mais ocasiões que podem quebrar a soma! Podemos também extender algumas funcionalidades e exibir mensagens de erro”.

Tivemos uma amostra do que é o SimpleTest em seu cenário mais simples: apesar do tamanho do post, o conceito e a aplicação são bem simples como puderam ver.

Além do assetEqual, a SimpleTest tem um set de ações enorme de validações, além de recursos mais avançados, como suites, mocks e web tests que veremos em breve.

Crie outras classes, pense nos testes, escreva seus casos de teste e vá executando: com a prática isso vai ficar tão automático que o ganho com a diminuição dos testes e bugs no final da aplicação vão ser notórios.

Testes nos tornam programadores melhores. Pense nisso.

Algumas coisas para se pensar quando começar a abordar isso:

• Não precisamos escrever TODOS os testes: é completamente normal se esquecermos algo ou houver alguma necessidade de mudança de negócio do cliente que nos fará escrever novos testes ou re-escrever os existentes. Tenha em mente que o TDD é para ajudar e não para ser mais uma fase carrancuda e intransponível no desenvolvimento;
• A análise para chegar aos casos de teste faz bem ao início do projeto: com essa abordagem, você pode fazer perguntas ao cliente (e ele a você) sobre algumas coisas que possívelmente só apareceriam no final do projeto gerando assim muito re-trabalho;

Bom, por enquanto é isso pessoal. No próximo post falaremos um pouco sobre agrupamentos de teste e partir para um exemplo mais complexo.

Espero que tenham gostado do post.

Simbora!

Estava rascunhando algumas coisas e fazendo umas melhorias num sistema na Giran, quando lembrei de duas perguntas que haviam sido feitas no 1º Workshop PHP-ES sobre CakePHP.

Aproveitando que lembrei delas mas não tinha a resposta na ponta da língua, ai vai uma dica sobre chaves primárias para ser feita no model de sua app. Isso está explicito no Cookbook, mas não muito à mão para quem está começando ou nos bilhares de screencasts existentes.

Modificando a chave primária ID

Se você está portando uma base de dados que já exista e que não segue a nomenclatura padrão do CakePHP, onde a chave primária da tabela é sempre chamada por id, utilize o atributo primaryKey do seu model para usar outro campo.

class Cliente extends AppModel {

var primaryKey = "CdCliente";

}

É com muita alegria que a comunidade PHP do Espírito Santo – PHP-ES – convida a toda a comunidade capixaba de desenvolvedores, gerentes de TI, estudantes, curiosos e a quem interessar para participar do 1º Workshop PHP-ES.

O Workshop PHP-ES é um evento regional totalmente dedicado à divulgação e disseminação da linguagem de programação PHP no ES. O evento acontece pela primeira vez, fruto da vontade dos usuários de grupo de PHP?ES em ter um evento exclusivo sobre PHP, afim de promover o interesse regional pela linguagem.

O Workshop PHP-ES será realizado no dia 30/05/2009, sábado, no período de 13h até as 18h no Anfiteatro da UVV – Centro Universitário de Vila Velha – Campus Boa Vista.

Equipe organizadora do Workshop PHP-ES

Salve pessoal,

É com prazer que informo as primeiras informações sobre o 1º encontro do grupo de usuários PHP do Espírito Santo, vulgo 1º Workshop PHP-ES. Esse evento vem sendo idealizado a algum tempo pela galera do grupo e finalmente saiu do papel graças ao empenho de todos (em especial do amigo Almir M3nd3s), com N threads no grupo de discussão e por ai vai.

O evento será realizado no dia 30 de maio, no Anfiteatro da UVV, a partir das 13:00. Isso vai cair num sábado e vai ser bem tranquilo. O ingresso será 1 Kg de alimento não perecível, que será doado para uma instituição de caridade que já está quase definida.

A idéia inicial do evento é apresentar algumas palestras relacionadas ao PHP e tecnologias de entorno, como por exemplo o jQuery, que faz parte do desenvolvimento web e está fortemente relacionada ao nosso mundo PHP.

Com base nesse pensamento, vão haver três palestras bem legais. Para simplificar, segue a programação prevista:

13:00h – 13:40h – Credenciamento
13:40h – 13:50h – Abertura
13:50h – 14:50h - Nadando em Dinheiro com AJAX e jQuery [Reinaldo de Souza "JuniorZ"]
15:00h – 16:00h - Desenvolvimento ágil com Smarty [Gerson Novais]
16:00h – 16:30h – Intervalo
16:30h – 17:30h - CakePHP [Leonardo "Hackin" Freire]
17:30h – Fechamento

Durante o evento, serão sorteados alguns brindes e no ato da inscrição cada um receberá uma caneta e, muito possivelmente, um bloco de papel para rascunhar o que quiserem.

Mais detalhes serão dados com o tempo, pois faltam fechar os patrocinadores e acertar algumas coisas. Para mais informações, cadastrem-se em nosso grupo (http://br.groups.yahoo.com/group/php-espiritosanto/) ou no blog do grupo (http://www.php-espiritosanto.com.br/wp/workshop-php-es/).

Contamos com a presença de todos.  =)