Category: php

Executando testes unitários em paralelo com o paratest

Não consigo contar o número de horas economizadas graças ao uso de testes unitários e todo o conceito de TDD. Mas o número de horas que eu gastava na execução de toda a suite de testes estava me irritando, por isso pesquisei por uma forma de melhorar este processo.

O primeiro passo foi otimizar ao máximo os códigos e estrutura dos testes mas chegou a um ponto que não consegui aumentar a performance apenas desta forma. Este é o momento que podemos partir para o próximo estágio, que é executar os testes em paralelo.

Encontrei duas ferramentas para executar esta tarefa, a PHPUnit Cluster Runner e o paratest. O ClusterRunner me parece bem mais completo e complexo, mas o paratest resolveu meu problema.

Foi preciso apenas alterar o composer.json do projeto para incluir:

"require": {
    "brianium/paratest": "dev-master"
}

e atualizar o vendors com o composer update.

Ao executar o comando ./vendor/bin/paratest é possível ver o seu help. As opções mais importantes são a -p que serve para indicar o número de processos e o -c para indicar onde está seu phpunit.xml com a configuração da sua suite de testes.

O que o paratest faz é criar um processo PHP para cada arquivo de sua suite de testes e executá-los em paralelo.

Rodando um ps -aux | grep php é possível ver os processos executando, algo como:

php vendor/bin/phpunit --configuration tests/phpunit.xml Api\Controller\RestControllerTest module/Api/tests/src/Api/Controller/RestControllerTest.php

Você pode usar o comando -f para que cada processo execute um teste apenas, um método de cada arquivo de teste. Ao rodar o ps -aux | grep php você deve ver algo parecido com isso:

php vendor/bin/phpunit --configuration tests/phpunit.xml --filter /testGetListNotFound(?:\s|$)/  module/Api/tests/src/Api/Controller/RestControllerTest.php

Como resultado do paratest eu consegui rodar um conjunto de testes grande, que estava demorando 17.67 minutos em apenas 4.91 minutos, usando 5 processo em paralelo.

Um ponto interessante foi que na primeira execução do paratest encontrei alguns testes que funcionavam perfeitamente quando executados em sequência, mas que davam erro ao serem executados em paralelo. Ou seja, não estavam seguindo corretamente o conceito de que cada teste não deve influenciar ou depender de outro.

Desta forma o paratest serve tanto para aumentar a performance da execução dos testes, algo muito útil em um ambiente de integração contínua, quanto como uma forma extra de validar seus testes.

elton

Elton Luís Minetto
No Code Squad, ministra os seguintes treinamentos: http://code-squad.com/perfil/eminetto#cursos-ministrados
Possui graduação e especialização em Ciência de Computação. Trabalha com PHP/MySQL desde 2000, com Linux desde 1997 e com MacOSX desde 2007. Também é autor do livro Frameworks para Desenvolvimento em PHP e co-autor do livro Grid Computing in Research and Education. É professor e co-fundador da Coderockr e Zend Framework Evangelist

Twitter

20 anos de PHP: Evoluir é sexy

A segunda-feira, dia 8 de Junho de 2015, marcou o aniversário de 20 anos da linguagem PHP.

Pouco tempo depois da linguagem ter sido criada ela foi lançada como Software Livre e hoje conta com mais de 700 programadores contribuindo para o seu desenvolvimento, incluindo Brasileiros.

Assim como em diversos outros acontecimentos na história destes 20 anos da linguagem, neste detalhe existe uma lição importante a ser aprendida.

Em 1995 o dinamarquês Rasmus Lerdorf decidiu, “do alto” dos seus quase 30 anos de idade tornar a linguagem que havia criado um Software Livre.

Rasmus_Lerdorf_August_2014_(cropped)

Embora eu tenha tido o privilégio de conversar com o próprio pessoalmente, é impossível para mim – ou para qualquer outra pessoa – imaginar como essa decisão pode ter sido difícil.

Trabalhamos em um mercado onde “complexo” é um termo diário.

O aprendizado muitas vezes acontece de hora em hora e a frequência com que nos descobrimos equivocados é muito maior do que imaginamos.

Um mercado onde impera a “Síndrome do Impostor”, como comentei em outro artigo.

Abrir o seu software para olhos alheios, portanto, é compreensivamente um processo que causa, pra dizer o mínimo, uma certa dose de ansiedade.

Uma vez mais o que nos impede e nos bloqueia é este orgulho tolo que temos de nossa suposta inteligência.

Todos queremos, em maior ou menor grau, nos tornarmos “a referência”, “o mestre”, “o gênio”.

O que custamos a aprender é que isso raríssimamente – se é que ocorre – acontece em um momento “Eureka!”, onde temos uma idéia genial depois de uma quase overdose de cafeína. E certamente não  acontece no isolamento de nossas próprias cabeças.

Neste nosso mercado complexo não existe aprendizado melhor do que abrir o seu código-fonte.

 

Ao fazê-lo você se torna imediatamphp-logo-php-721782ente um alvo, mas isso não precisa necessariamente ser algo negativo: ao receber críticas ao seu trabalho você pode refutá-las por teimosia, refutá-las com argumentos ou aceitá-las – com ou sem argumentos.

Você pode aprender sobre aquele design pattern que parecia impossível de entender.

Você pode descobrir que o mercado recomenda soluções diferentes das suas e, principalmente, entender o motivo dessas recomendações.

E você pode até mesmo – veja só – descobrir que a sua solução tem uma aceitação muito maior do que você imaginava.

Independente do resultado, o importante é que você aprende.

  • Aprende alternativas para o que você está trabalhando;

  • Aprende o quanto você tem razão… e o quanto não tem;

  • Aprende a defender os seus posicionamentos;

  • Aprende a aceitar os seus erros e, tão importante quanto, crescer com eles;

  • Aprende que não existem “obras-primas” que tudo neste nosso mercado evolui.

A linguagem PHP evoluiu tremendamente nestes 20 anos, tornando-se a linguagem que está presente em mais de ¾ de todos os servidores conectados a web no mundo. Falo disso em uma palestra que já tive o prazer de apresentar em diversas instituições e eventos, e esta palestra, que muito pouco tem de técnica, atrai sempre a atenção e os elogios do público. A razão de toda essa atenção e elogios é simples: a evolução é sexy.

Sim, você leu certo: Evoluir é sexy.

É um processo extremamente difícil, muitas vezes doloroso, mas ao vermos os benefícios deste processo é impossível não nos encantarmos.

É impossível não sorrirmos hoje, passados estes 20 anos, quando lembramos o quanto a linguagem foi vítima de críticas injustas, piadas tolas e previsões de sua morte prematura.

Foram dificuldades que tornaram o processo de evolução feio, difícil e caótico, mas isso tudo faz parte de um processo evolutivo, de aprendizado e crescimento.

Aprendemos a rebater as críticas injustas, aprendemos a ignorar as piadas tolas e aprendemos a rir dos futurólogos do mercado, que adoram prever a morte das coisas.

Hoje, 20 anos depois, aprendemos que podemos nos tornar “um Rasmus da vida”, se estivermos dispostos a encarar as dificuldades.

E ao olhar para o PHP 5.6.9 e dar aquela “espiadinha” no que vem por aí no PHP 7, aprendemos o quanto algo pode evoluir ao se tornar coletivo e o quão brilhante pode ser o futuro.

Vida longa ao PHP!

Referencias:
Histórico da Logo do PHP: http://blog.tetranet.com.br/o-motivo-de-o-mascote-simbolo-do-php-ser-um-elefante/

Er Galvão Abbott
No Code Squad, ministra os seguintes treinamentos: http://code-squad.com/perfil/galvao#cursos-ministrados

Er Galvão Abbott – É o Presidente da ABRAPHP – Associação Brasileira de Profissionais PHP, Diretor da PHP Conference Brasil, o principal evento de PHP da América Latina e fundador do PHPBR, Grupo de Usuários com mais de 1.200 associados. Trabalha há mais de 20 anos desenvolvendo sistemas e aplicações com interface web, sendo 15 anos com PHP e 7 anos com Zend Framework. Trabalhou com diversas empresas de grande porte, tanto nacionais como internacionais. Palestra em eventos e ministra cursos em diversas instituições, bem como in company. – See more at: http://code-squad.com/perfil/galvao#perfil

Twitter

Usando o Deployer

Segundo a Wikipedia, “software deployment” significa:

“todas as atividades necessárias para tornar um software disponível para uso”

Esta lista de atividades pode ser algo simples como enviar um diretório de arquivos para um FTP ou um processo complexo, envolvendo migrações de banco de dados, múltiplos servidores, vários níveis de cache, etc.

Geralmente o processo de deployment automatizado é uma sequencia natural do processo de integração contínua e exitem diversas ferramentas e formas de se automatizar esse processo, tanto gratuitas quanto pagas.

Vamos considerar os dois extremos de complexidade no quesito deploy automatizado.

De um lado o mais simples: um shell script que realiza uma série de comandos Linux (ou outro sistema operacional) para colocar o software em produção.

De outro lado um sistema de deploy ligado a uma ferramenta de integração contínua como o Jenkins, Codeship ou Travis.

Em dois projetos de clientes da Coderockr resolvemos adotar uma solução intermediária: scripts PHP.
imagem-artigo-elton-deploy

Para isso estamos usando o Deployer.

Continue reading

Twitter

© 2017 Bussola Code Squad

Theme by Anders NorenUp ↑