Cairo’sBlog

Nomeando os testes? E isso é relevante? Eu não sei para você mas isso faz total diferença.

Um teste chamado ValorVerdadeiro é diferente de um teste chamado ValorDaVariavelFooDeveSerVerdadeiro, a diferença não está no fato do código ser diferente, mas na percepção que temos ao ler isso. Ao ler ValorVerdadeiro o nome desse teste oculta o que ele realmente quer fazer. E nós não queremos ocultar nenhum teste, ou omitir o que os testes querem mostrar ;)

A nomeação de um teste não passa só por isso, as vezes, quando não sabemos nem o que testar, quando nomeamos um teste de maneira correta temos um gancho para sabermos o que queremos com esse teste e como vamos implementá-los.

E o nome do teste deve ser claro para que qualquer um possa saber o que você está querendo, em times mistos e com várias pessoas a integração fica bem maior. Ou para um novo desenvolvedor na empresa/projeto, você não precise de imediato explicar para ele todos detalhes do projeto, mas pode mostrar e pedir para ele ler os testes e tentar entender o que está acontecendo ali, é bem mais produtivo. (Se ele for bom, ele pega boa parte da lógica do sistema ao ver os testes).

Coloquem nomes legais e façam uma identidade unica para cada teste, isso pode salvar a pele de vocês um dia, quando um dos testes resolver não funcionar! Você de cara já vai entender o contexto do teste.

Eu twittei um dia desses se eles leriam sobre uma série de artigos sobre o PHPUnit e a resposta foi SIM :)

Eu já escrevi aqui sobre o PHPUnit e até uma vez eu disse que ia fazer uma série, comecei como fazer a instalação, aqui tem relatos tanto de windows como de linux, ensinei como integrar o PHPUnit ao CodeIgniter sem o uso de mocks e stubs (por falta de experiência, não é legal) e mostrei como fazer alguma coisa com o PHPUnit.

Mas o que quero mostrar nessa série é algo real, casos reais que eu enfrentei e como eu testei.

Eu vou explanar falando sobre o cake, um projeto estou trabalhando :)

O que eu realmente aprendi com o PHPUnit é que ele não é um simples framework de testes, na realidade, aprendi com todos os tipos de testes que já fiz (RSpec, Test::Unit, Cucumber, SimpleTest). Testes é apenas uma forma racional de você pensar em como desenvolver. Se você não tem a mínima idéia do que você quer saber, teste. Se tem bastante idéia do que você quer fazer, teste. Se você quer ter certeza do que está fazendo, teste! Em qualquer caso que você imaginar, teste!

Criando testes, você força a sua mente a pensar no comportamento da aplicação, na unidade de seus objetos e no que realmente você precisa. Eu já li a respeito de testes, e todos os autores afirmam, testes é uma filosofia, não é somente fazer você escrever menos e fazer mais, mas é realmente uma filosofia, existe pessoas que não conseguem criar guiado a testes, mas nem por isso são péssimos profissionais, é uma filosofia, vai de cada uma.

Você muda a sua forma de pensar, se você não está querendo ou não quer mudar, nem comece a tentar entender o que e para que serve todos esses frameworks, pois você está no caminho errado. Para começar a desenvolver orientado a testes, é necessário que você mude, que você programe menos e pense mais!

Essas últimas semanas está sendo corrida… Estou acertando todos os detalhes para o PHP Conference, e é por que ainda não cheguei por lá, quando chegar, terá mais coisas para fazer :)

Esse post é para apenas lembrá-los que a Add4 Comunicação estará fazendo parte do PHP Conference e nós queremos vocês com a gente :)

Eu chego em São Paulo no dia 27. Tem um #NoB marcado, quero ir, alguém me leva?! :P

O PHP Conference vai acontecer nos dias 27, 28 e 29 e será recheada de PHPzeiros e Nerds. Espero conhecer muita gente boa.

Nos encontramos lá :)

Este artigo é uma tradução do artigo Refactoring your legacy code - Part One: In the beginning there was…, caso você encontre erros de português, concordância, tem algum comentário ou agradecimento, FAÇA! É como um amigo meu sempre fala, se você ver alguma coisa errada, conserte!

Lars Jankowfsky é desenvolvedor PHP e participou da International PHP Conference 2008. Ele possui o Frontalaufpral onde ele fala sobre PHP, Agile Development e outros assuntos.

Deixa de papo e vamos a tradução!

Refatorando seu código legado - Parte Um: No início houve…

Como prometido, Tomas e eu iremos procurar mostrar uma visão sobre o que você precisa considerar quando você planejar refatorar suas velhas (legadas) aplicações. Não será um guia detalhado nem muito ordenado. Será mais ou menos nossas experiências e pensamentos nos últimos anos.

Se você precisa de uma introdução mais detalhada (incluindo a nível de código) você deve participar de nosso workshop na Internation PHP Conference 2008. Eu irei ministrar o workshop juntamente com dois dos melhores programadores PHP (Johann Peter Hartmann e Thorsten Rinne), você pode esperar muito mais detalhes.

Com certeza eu irei publicar a apresentação após o IPC - mas não antes ;)

Agora - Refatorando, hmm… Refatorar é, por definição, o meio de modificar (limpando) sem alterar o comportamento. Mas como você pode ter certeza que não está mudando o comportamento se você não está fazendo testes? Isto significa - você só pode refatorar um código se ele possui testes. E é aqui que começa o problema - onde está os testes?

E lá vamos nós. Vamos assumir que você possui um grande projeto - que cresceu durante anos. E agora você está na sorte que seu chefe concorda com você sobre a necessidade dos testes. Mas como iniciar? O time não possui experiência escrevendo testes. Pior ainda, nem sabem o que é Test Driven Development.

Você precisará investir um tempo no time para que eles aprendam como escrever testes. E você experimentará que conhecer e compreender são duas coisas diferentes. Na minha opinião, somente uma coisa pode ser comparada. A diferença entre programação procedural e orientada a objetos. Estranho exemplo? Não.

Deixe-me explicar. É muito fácil pegar um livro e aprender um pouco sobre classes, objetos, etc. Mas somente depois de você usar por um tempo é que você entenderá profundamente o conceito de OOP e buscar o bom senso. O mesmo é para o TDD - escrever testes é mais ou menos questão de minutos. Ou digamos horas se for o seu primeiro teste. Mas entender por quê os testes são importantes e como usá-los. Isto precisa de tempo. E você terá que investir esse tempo.

Depois de eu ter empurrado o time dentro desta direção ( e ei! - isto não foi tão fácil, como muitos desenvolvedores tendem a ser mais conservadores), eles fizeram os testes - simplesmente por quê o chefe disse isso. Mas somente poucas semanas depois, um desenvolvedor disse-me “Ei! Testes são legais! Eu encontrei um bug, eu nunca teria encontrado antes”. Este é o ponto que você precisa para o seu time.

Um pouco mais de teoria. Mas o que dizer dos testes? Por onde começar? Essa resposta é fácil. Você precisa começar com o mais sórdido, mais sujo, e maior arquivo que você pode achar no seu projeto. Eu sei, Eu sei. Eles querem começar com os arquivos mais fáceis, onde os testes são feitos rapidamente e você ver algum progresso. Os desenvolvedores realmente terão medo deste arquivo. Mas o que vai acontecer se você iniciar pelos fáceis? Simples - você verá algum progresso e terá a sensação que as coisas estão tudo bem. Seu time não entenderá os testes completamente - e eles deixam as partes mais sórdidas do código para o final. Você tem que ter forças para resolver os demônios logo no começo. Isso vai demorar um pouco. Mas então você pode ter certeza que o restante vai ser um bom e delicioso pedaço de bolo. De outro modo, você irá mover o parte do risco para o fim do período de refatoração -  e isto não é uma boa idéia.

Você poderia pensar “Esse cara é louco, onde está o problema em escrever testes…?” Ei! Nós estamos falando de velho código crescido ( == espaguete ). Este código é massivamente interconectado. Variáveis globais, classes mistas, selvagens chamadas entre módulos e objetos, etc. É muito difícil escrever testes para isto.

Na verdade, enquanto estiver escrevendo testes você notará que precisa refatorar o código. Você simplesmente tem que refatorar. Pois de outra forma você não pode escrever os testes. Ou - vamos ser honesto - você pode. Se você escrever mocks e stubs que é o triplo do tamanho do seu código. Isto é exatamente o que desenvolvedores sem experiência com TDD irão fazer. Se você ver isso - chutem eles! E em seguida novamente, por que a sensação é muito boa ;).

Cada teste leva ao refatoramento. Como o nó górdio (Vejam no wikipedia) você começará a puxar o worm, e irá puxar, puxar e puxar. E após algum tempo a refatoração estará pronta e o primeiro teste pode ser escrito. Ok, só estava brincando. Mas há alguma verdade nesta afirmação. Você precisa refatorar o código primeiro - então escrever o teste. Sem grandes stubs.

E isto será trabalhoso - especialmente no início, onde tudo está interconectado. E algumas dependencias precisam ser abordadas e resolvidas. Primeiro. Separe o modelo da visão. Na visão, deixe sem lógica - somente I/O. E então teste o modelo. Algumas pessoas até mesmo testam as visões com testes unitários. Eu não. Eu prefiro testar o modelo, com pequenas visões sem lógica e deixar o resto para os testes com selenium.

O sórdido. Leva tempo. Muito trabalho. Mas acredite em mim. Não há outra forma.

Durante a leitura, você pode ficar com a idéia de que você vai fugir com os testes de aceitação. (selenium). Você acha que isso é um bom negócio? A idéia é sensacional. Se você escrever testes do selenium para toda a aplicação - então refatorar - e você não quebrar nenhum teste, você pode ter certeza que você não alterou qualquer funcionalidade. Boa ideia? Não vai funcionar. Desculpe

Lembre-se. Eu estou falando de uma grande aplicação que cresceu. Ela terá toneladas de funcionalidades. Isto significa centenas ou milhares de testes. E estes testes podem durar muito. Eu sei disso. Eu fui até esta estrada - e ela é uma estrada de mão uníca. Nós terminamos com um teste completo rodando por 10 horas. Isso não é desenvolvimento guiado a testes. Para fazer isso que você precisa instantaneamente - instantaneamente - de feedback. Ninguém pode trabalhar assim.

Contínua na parte dois.

Essa foi a primeira parte do artigo. Mais uma vez, espero que vocês gostem. Qualquer dúvida entre em contato! Não deixe de me passar seu feedback.

Olá, hoje eu lancei o cake e primeiramente, não, não é nada relacionado ao cake PHP. Ele tem esse nome por que é um acrônimo de CodeIgniter mAKE.

Mas o que ele faz?

Ele aumenta a velocidade para você trabalhar com CodeIgniter. Ele tem a mesma funcionalidade dos scripts/generate do Ruby On Rails, apenas criando uma estrutura para seu projeto CodeIgniter.

Ele cria magicamente controllers, views e models.

E o que ele gera?

Bom, no momento ele está gerando controllers e models, e com um aperitivo a mais, ele está gerando também as views passada como parâmetro para gerar os controllers.

Outra coisa ele está o seguindo padrão nomeController.php e o nome da classe como NomeController, para os models está criando as classes como nome.php e Nome.

As views estão sendo geradas em nome_controller/ com o sufixo _view.php, algo como nome_controller/index_view.php.

Ele é verboso, então ele vai dizendo o que está sendo feito a cada passo.

Como faço pra usar?!

Eu escrevi um Read Me bem simples, assim mesmo para quem não está muito bem no inglês possa entender.

O que eu espero para o futuro?

Atualmente só tem suporte ao linux e ao macOS, então quem se interessar em portar para funcionar no windows, fique a vontade ;) (Os scripts que geram os arquivos estão em php então independe de OS para funcionar, o que falta é o script funciona no windows, que se não me engano é necessário fazer os bats e configurar a PATH, isso é quase a solução :).

Bom, primeiramente vou ajustar para também gerar rotas padrões para cada controller.

Depois vou adicionar opções como nomenclaturas diferentes.

Vou adicionar também um suporte para gerar os testes para controllers e models.

E gostaria de incluir a opção de baixar a versão mais nova do CodeIgniter e criar a estrutura do projeto, algo como cake –app nomeDaApp e cake –update.

O projeto está sobre licença Creative Commons 3.0, você pode usar comercialmente, modificar e distribuir, apenas mantendo meus créditos!

e o mais importante: VOCÊ PODE CONTRIBUIR, só ir lá no github, fazer um git clone e depois me mandar um pull request ou um patch :P

Até a próxima!

A semana passada foi movimentada no PHP. Para quem ainda não sabe Namespaces é a forma conveniente de agrupar e distribuir bibliotecas, para quem já programa em Java são os velhos pacotes e quem programa em ruby são os módulos.

E só agora o PHP está querendo colocar no seu Core o uso de namespaces, que vai ser uma boa forma de programar, adicionando mais paradigmas legais em PHP.

Mas a grande confusão que se teve na semana passada, foi sobre a forma de requisitar os Namespaces.

No início, seu uso seria com 3 dois pontos ( ::: ), depois mudaram para 2 dois pontos ( :: ) e viram que haveria conflito com chamadas estáticas e por fim decidiram o uso de uma barra invertida ( \ ), como por exemplo:

MeuNameSpace:::metodo();

MeuNameSpace::metodo();

MeuNameSpace\metodo();

Mas com isso surgiu vários problemas como poder ser facilmente trocado por \, \ é usada para escapar strings entre outros problemas. Aqui você pode ver com detalhes a discussão sobre NameSpaces.

Depois de toda essa discussão, quem já estava querendo no próximo release utilizar namespaces, pode ir tirando o cavalinho da chuva :P

Agora é aguardar e observar as próximas decisões do CoreTeam do PHP.

Talvez em alguns dias o phpBURN ganhe vida própria! :P

Se você quiser seguir clica aqui.

No dia 20/10 foi lançado a versão 3.3.2 desse framework de testes.

Foram adicionados algumas funcionalidades e corrigidas vários bugs. Quem já tem instalado o PHPUnit sobre o pear, apenas faça o upgrade

sudo pear upgrade phpunit/PHPUnit

quem ainda não tem, é uma boa hora de começar a instalar ;)

Quer ganhar?! Então faz o seguinte:

Escreve uma frase bem legal sobre o que você ai encontrar lá, imagina aí um milhão de coisas :P

As duas melhores frases vão ganhar um ingresso para curtir o PHP Conference junto com a galera da Add4 Comunicação!!

Então não vacila, da uma olhada aqui e tenha mais detalhes sobre essa promoção :D

Nós migramos o PHPBurn para o GitHub, então se você tiver vontade de nos ajudar a transformar este ORM faça um fork do projeto e depois nos mande um pull request!

Outra coisa é que quem estiver afim de ganhar uma camiseta, ter um desconto na entrada da PHP Conference 2008 e se juntar a galera da Add4 Comunicação, basta entrar em contato por aqui ou por comercial at add4 ponto com ponto br.

Vamos mudar o mundo, fazer um ORM que consuma menos memória, seja mais rápido, menos burocrático, mais simples e fácil de usar, assim ajudaremos a natureza reduzindo consumo de energia e diminuindo a emissão de CO² :P