locust-logo

Efetuando teste de carga com o Locust

Os testes de carga consistem em colocar uma demanda em um sistema de software ou dispositivo e medir a sua resposta. Este tipo de teste é realizado para determinar o comportamento de um sistema sob condições normais e picos de carga. Ela ajuda a identificar a capacidade máxima de operação de uma aplicação, bem como os gargalos e determinar qual elemento está causando lentidão.

Uma das ferramentas mais conceituadas nesse tipo de testes é o Apache JMeter™, porém hoje iremos abordar o Locust, uma ferramenta escrita em Python extremamente simples e poderosa.
(mais…)

codeception-logo

Codeception, testes de interface

Fala galera,

Mais uma vez falando sobre o Codeception, no post passado mostrei como fazer o setup inicial e como começar a usá lo com testes unitários. Clique aqui para ver o post anterior.

Testes unitários são provavelmente o primeiro tipo de teste que você vai ver em qualquer tutorial, são os testes mais simples de serem feitos e provavelmente, os mais importantes. São os testes unitários que vão testar as suas funções, as suas classes, as suas regras de negócio e sua integração com o banco. Para este último, apesar de na prática não há diferença, existe uma especialização dos testes unitários, que são os testes de integração. A diferença entre um teste unitário e de integração é basicamente que o teste de integração faz acesso a um recurso externo, seja ele um banco de dados, uma API, ou qualquer outra coisa. Não irei abordar esse tipo de teste aqui, pois na prática os testes de integração são testes unitários.
(mais…)

Laravel 5

Laravel 5 do começo ao fim [parte 4]

Neste post veremos uma peça fundamental de um workflow que tento sempre seguir, o famoso “TDD”, que em tradução livre ficaria algo como “Desenvolvimento Orientado a Testes”, que seria a parte de teste com Laravel 5, caso não tenha visto, veja outras partes dessa série nos links abaixo:

Algo que muitos programadores simplesmente ignoram, seja por preguiça ou qualquer outro motivo obscuro, é a parte de automação de testes. Muitos ainda utilizam a velha prática de testar na mão as funcionalidades do software, porém isto não é algo recomendado uma vez que existem grandes chances de você simplesmente esquecer de realizar algum teste importante de alguma funcionalidade, além de claro, esse processo é extremamente maçante e sinceramente  desnecessário ser realizado por mentes humanas.

O objetivo dos testes basicamente é encontrar falhas, através da execução de funções ou conjunto de funções do software, comparando os resultados obtidos das execuções dessas funções com resultados previamente conhecidos.

Existem diversas ferramentas disponíveis para a automação de testes no PHP, algumas possuem um nível extremamente detalhado de definição dos testes a serem realizados, outros são mais “simples” de serem usados, podemos citar aqui algumas como o PHPUnit, Behat, PHPSpec, entre outros.

O Laravel, assim como praticamente todo framework que se prese, prevê que o usuário programador teste seu programa. Para isto ele utiliza de fábrica basicamente duas ferramentas, o PHPUnit, muito comumente utilizado, e o PHPSpec, outra ferramenta muito boa que cheguei a utilizar bastante e possui um conceito muito interessante de teste, contudo por ser considerado um padrão no mundo PHP utilizaremos o PHPUnit, uma ferramenta para testes unitários.

Mãos na massa

Vamos primeiramente dar uma olhada nos arquivos de testes que já vêm junto com o Laravel.

Na raiz do projeto você verá que existe uma pasta chamada “tests”, como é de se esperar esta pasta contém todos os arquivos de testes do seu projeto.

Inicialmente você verá dentro desta pasta basicamente dois arquivos: “ExampleTest.php” e “TestCase.php”, abra o primeiro arquivo, você verá algo como o mostrado abaixo.

Como podemos ver, neste arquivo existe uma classe chamada “ExampleTest”, uma classe de exemplo que vem por padrão na instalação do laravel, essa classe estende de outra classe chamada “TestCase”, a classe da qual todos seus testes devem estender, que está no outro arquivo presente nesta mesma pasta.

Observação : Abaixo citarei alguns padrões utilizados pelo PHPUnit, para mais informações e maiores detalhes do framework de testes, visite sua página oficial aqui

Antes de mais nada, vamos esclarecer algo, uma boa prática para testes responde o que é provavelmente uma das dúvidas que fica nas pessoas sobre o tema, “O que afinal devo testar ?”, por via de regra você deve testar TODAS as funcionalidades do seu sistema para ter certeza que está tudo funcionando. Uma outra dúvida que também pode estar presente é como testar, por via de regra você deve tentar ao máximo simular o usuário, tente testar as operações da maneira como o usuário ou o programador as utilizaria e com os resultados que eles esperariam.

Continuando, na classe “ExampleTest”, existe uma função chamada “testBasicExample”, sem entrar em maiores detalhes do que está sendo feito por trás, apenas observando os nomes das funções usadas, podemos deduzir que na primeira linha está sendo feito uma chamada para a URL “/” com o método “call”, usando o verbo GET que vimos no post anterior, e logo após na linha seguinte está sendo verificado.

No PHPUnit, é uma boa prática, porém não é obrigatório criar uma classe de testes para cada classe do seu projeto, usando o sufixo “Test”, e todas as funções de teste ou tem o prefixo “test” no nome ou possuem a tag @test como comentário antes da função para serem reconhecidas pelo PHPUnit, além disso os métodos ou funções de verificação de valor tem o prefixo “assert” que em inglês significa “afirmar”, ou seja, você está afirmando que o valor de resultado da função passada como parâmetro corresponde ao outro valor passado como parâmetro, testar é isso, você passa uma função e compara se o valor retornado é o que você esperava.

Vamos alterar essa função para verificar se nossa rota de tarefas está funcionando, mude o código para o mostrado abaixo:

$response = $this->call('GET', '/tarefa');

Por fim, é necessário que o PHPUnit execute nossos testes, vá com o terminal na pasta raiz do projeto e execute o seguinte comando:

vendor/bin/phpunit

Basicamente o PHPUnit carrega as configurações do arquivo “phpunit.xml” na pasta raiz e procurará todos as funções de testes presentes na pasta “tests”, executando-as. O resultado mostrado esperado é que não ocorra nenhum erro, e portanto uma mensagem como “OK (1 tests, 1 assertions)” em verde deve ser mostrada.

Bem pessoal a parte de testes com o PHPUnit é bastante extensa, não espero abranger tudo num único post, contudo caso queiram mais detalhes peço que vejam a documentação oficial do PHPUnit, ela é bastante abrangente, e pelo amor das minhas linhas de código TESTEM SEUS PROGRAMAS!!!, até a próxima o.

7b5b9071afbe94c1cfff78b1ce5721e5

Fedora 23 irá trocar o X.Org Server pelo Wayland

Enquanto muito se falava em trocar o X.Org Sever pelo Wayland como sendo algo distante, parece que o Fedora 23 irá fazer acontecer.

O Fedora 23 já tinha algumas metas ambiciosas, como ter seu suporte somente para 64-bits, e agora desejam utilizar o Wayland como servidor gráfico padrão. No Fedora 21 o Wayland já estava presente no Fedora Workstation, mas ainda dependente do X.Org Server. No Fedora 22 a experiência com o Wayland será melhor, e finalmente no Fedora 23 irá ser feita a troca.

Mathias Clasen da Red Hat escreveu uma postagem em seu blog intitulada “GNOME Wayland porting – the endgame” (O port do Wayland no GNOME, fim de jogo). Este post fala sobre as inúmeras características do Wayland que irão aparecer em breve nas builds de desenvolvimento do GNOME, sobre as características restantes do X.Org Server que precisam ser implementadas no Wayland e etc. Uma importante meta do Fedora 22 é a utilização do Wayland na tela de login. Utilizando o Wayland como tela de login do GNOME irá expô-lo a diferentes tipos de drivers/dispositivos, além de expor possíveis bugs antes da efetiva troca.

Após o lançamento do Fedora 22, o Wayland será ativado por padrão no Fedora Rawhide, o que significa que Wayland será padrão no Fedora 23, se nada der errado no *Rawhide. Portanto pelo calendário de liberação, poderemos ver o Fedora 23 com o Wayland antes do fim deste ano. Fedora 23 com Wayland irá “brigar de frente” com o Ubuntu 15, uma vez que este poderá vir com o novo Unity 8 e utilizar o Mir como servidor gráfico no desktop.

* Rawhide é a versão de desenvolvimento do Fedora. Uma vez que uma versão é lançada, um Rawhide é criado para que os desenvolvedores e testadores possam ir pegando erros até que este fique estável o bastante para o lançamento da próxima versão.

Via Phoronix

i-want-you-1-238x300

openSUSE 13.2: Chegou a hora de testar

Menos de três semanas se passaram desde o lançamento da primeira versão release candidate e já podemos sentir que estamos quase lá. Este é o momento certo para lembrar que ainda há muito trabalho a fazer e muita diversão para se ter. O Open Source é incrível, mas não tão impressionante como as pessoas que trabalham nele. Nada vai acontecer se você não fazer isso acontecer, então está na hora de sujar as mãos!

Cada versão do openSUSE é testada usando openQA, o que poupa os desenvolvedores de trabalho trivial e repetitivo. Mas, a fim de atingir o nível de qualidade que todos nós amamos das versões estáveis do openSUSE ​​é necessário muito mais testes. Nós gostaríamos de testar cada combinação de hardware, desde netbooks a super computadores. Então, por favor, dê uma olhada na planilha on-line que foi criada para organizar o teste manual, leia as instruções de testes e vamos caçar todos os bugs!

Via Blog openSUSE