PythonClub - A Brazilian collaborative blog about Python: Python com Unittest, Travis CI, Coveralls e Landscape (Parte 1 de 4)

Fala pessoal, tudo certo?

Durante o desenvolvimento de um software, tão importante quanto escrever um código organizado e que siga as melhores práticas, é garantir que o mesmo cumpra os requisitos a que ele se propõe. Em outras palavras, garantir que o software funcione de maneira adequada.

O processo de testes de um software faz parte do seu desenvolvimento, porém muitas vezes ele é encarado como algo tedioso e desnecessário. Entretanto, todo bom desenvolvedor sabe que investir tempo escrevendo testes para seu software está longe de ser "desperdício de tempo". O processo de teste, quando feito por uma pessoa, além de sujeitos a falhas é tedioso e demorado. Tendo isso em mente, podemos lançar mão de ferramentas que realizarão o processo de teste por nós. Em Python, umas das ferramentes da bibloteca padrão destinada a teste é a Unittest, que usaremos nesse tutorial.

Nesta série de postagem, irei mostrar o passo-a-passo na criação de testes unitários para um pequeno projeto que vamos criar no github. Vou explicar como configurar a ferramenta Travis, que será responsável por executar os nossos testes no github. A ferramenta Coveralls, que mapeia nosso código, e nos indica o quanto dele está coberto por testes. E como bônus, adicionar ao nosso projeto o Landscape, ferramenta que monitora a "saúde" do nosso código.

Iniciando nosso projeto

Inicialmente, criei no github um repositório que vai receber meu código e que posteriormente será configurado para rodar nossos testes. No meu caso, o repositório foi esse codigo-avulso-test-tutorial. Após realizar o clone, criei a seguite estrutura de diretorios:

.
├── codigo_avulso_test_tutorial
│   └── __init__.py
├── LICENSE
├── README.md
└── test
    └── __init__.py

O diretório codigo_avulso_test_tutorial receberá o código da nossa aplicação e o diretório test receberá o código de teste. O nosso projeto consiste de um grupo de classes representando figuras geométricas (quadrados, círculos e etc). Teremos uma classe base chamada FiguraGeometrica que possui dois métodos, a saber: get_area e get_perimetro, sendo ambos metódos abstratos. Cada uma dessas classes filhas de FiguraGeometrica irá possuir sua própria implementação desses métodos.

Dentro do diretório codigo_avulso_test_tutorial, irei criar os fontes do nosso código:

touch figura_geometrica.py circulo.py quadrado.py

Dentro do diretório test, irei criar os fontes do nosso código de teste:

touch figura_geometrica_test.py circulo_test.py quadrado_test.py

Uma observação importante é que os arquivos de teste devem ter o nome terminado em test, para que o módulo de Unittest encontre os nossos arquivos de teste automaticamente. Após a criação dos arquivos, teremos a seguinte estrutura de diretório:

.
├── codigo_avulso_test_tutorial
│   ├── circulo.py
│   ├── figura_geometrica.py
│   ├── __init__.py
│   └── quadrado.py
├── LICENSE
├── README.md
└── test
    ├── circulo_test.py
    ├── figura_geometrica_test.py
    ├── __init__.py
    └── quadrado_test.py

Iniciemos agora a implementação do nosso projeto. Mas antes vamos dar uma olhada em alguns conceitos.

Test Driven Development (TDD)

Neste momento, leitor, você deve estar se perguntando: "Não deveríamos escrever primeiro o nosso código e depois escrever os testes?".

Não necessariamente. O processo de escrever os testes antes do código é chamado de TDD - Test Driven Development. Segundo a wikipedia:

"Test Driven Development (TDD) ou em português Desenvolvimento guiado por testes é uma técnica de desenvolvimento de software que baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste para posteriormente o código ser refatorado para um código sob padrões aceitáveis. Kent Beck, considerado o criador ou o 'descobridor' da técnica, declarou em 2003 que TDD encoraja designs de código simples e inspira confiança[1] . Desenvolvimento dirigido por testes é relacionado a conceitos de programação de Extreme Programming, iniciado em 1999,[2] mas recentemente tem-se criado maior interesse pela mesma em função de seus próprios ideais.[3] Através de TDD, programadores podem aplicar o conceito de melhorar e depurar código legado desenvolvido a partir de técnicas antigas.[4]"

Criando o setup.py

Antes de começar a implementar o códigos de teste, vamos criar o arquivo setup.py. Esse arquivo contém informações sobr e o nosso módulo python e facilita em muito a utilização dos testes. Então, vamos criar o arquivo setup.py na pasta raiz do nosso projeto.

touch setup.py

A estrutura do nosso projeto agora está assim:

.
├── codigo_avulso_test_tutorial
│   ├── circulo.py
│   ├── figura_geometrica.py
│   ├── __init__.py
│   └── quadrado.py
├── LICENSE
├── README.md
├── setup.py
└── test
    ├── circulo_test.py
    ├── figura_geometrica_test.py
    ├── __init__.py
    └── quadrado_test.py

Abra o setup.py em um editor e adicione as informações conforme exemplo abaixo:

# -*- coding: utf-8 -*-fromsetuptoolsimportsetupsetup(name='codigo-avulso-test-tutorial',packages=['codigo_avulso_test_tutorial','test'],test_suite='test',)

No código acima, name representa o nome do seu projeto, packages são os diretórios do seu projeto que possuem código fonte e test_suite indica o diretório onde estão os fontes de teste. É importante declarar esse diretório pois o Unittest irá procurar dentro dele os arquivos de teste que iremos escrever.

Criando testes para a classe FiguraGeometrica

Agora, vamos usar a lógica do TDD. Primeiro criamos o código de teste de uma classe para em seguida criamos o código da mesma. Das classes que criamos, o arquivo figura_geometrica.py servirá como uma classe base para as outras classes. Então vamos começar por elá.

Abra o arquivo figura_geometrica_test.py e seu editor preferido e adicione o código abaixo:

# -*- coding: utf-8 -*-fromunittestimportTestCasefromcodigo_avulso_test_tutorial.figura_geometricaimportFiguraGeometrica# O nome da classe deve iniciar com a palavra TestclassTestFiguraGeometrico(TestCase):# Serve para incializar variavei que usaremos# globalmente nos testesdefsetUp(self):TestCase.setUp(self)self.fig=FiguraGeometrica()# Retorna uma NotImplementedError# O nome do metodo deve comecar com testdeftest_get_area(self):self.assertRaises(NotImplementedError,self.fig.get_area)# Retorna uma NotImplementedError# O nome do metodo deve comecar com testdeftest_get_perimetro(self):self.assertRaises(NotImplementedError,self.fig.get_perimetro)

Como podemos observar no código acima, a seguinte linha:

deftest_get_area(self):self.assertRaise(self.fig.test_get_area(),NotImplementedError)

Realiza o seguinte teste. Com o objeto self.fig criado no método setUp(), tentamos chamar o método test_get_perimetro da classe FiguraGeometrica, porém ele verifica se ocorreu a exceção NotImplementedError. Isso é feito porque a classe FiguraGeometricaé uma classe abstrata e possui ambos os métodos get_area e get_perimetro vazios. Isso irá ficar mais claro quando adicionarmos o código da classe FiguraGeometrica. Então, abra o arquivo figura_geometrica.py em seu editor e vamos adicionar o seguinte código:

# -*- coding: utf-8 -*-classFiguraGeometrica(object):# Retorna a area da figuradefget_area(self):raiseNotImplementedError# Retorna o perimetro da figuradefget_perimetro(self):raiseNotImplementedError

A class acima é bem simples. Ela possui um método que retorna a área e outro que retorna o perímetro da figura. Ambos são métodos abstratos, ou seja, devem ser implementados nas classes filhas da classe FiguraGeometrica. Se criarmos um objeto dessa classe e chamarmos um dos dois métodos, uma exceção do tipo NotImplementedError será lançada, pois ambos os métodos possuem escopo vazio.

Finalmente podemos executar o teste da nossa classe. Usando o terminal, no diretorio em que o arquivo setup.py está, execute o seguinte comando:

python setup.py test

Esse nosso comando vai executar a nossa classe TestFiguraGeometrica. Se tudo estiver correto, teremos a seguinte saída:

running test
running egg_info
writing codigo_avulso_test_tutorial.egg-info/PKG-INFO
writing top-level names to codigo_avulso_test_tutorial.egg-info/top_level.txt
writing dependency_links to codigo_avulso_test_tutorial.egg-info/dependency_links.txt
reading manifest file 'codigo_avulso_test_tutorial.egg-info/SOURCES.txt'
writing manifest file 'codigo_avulso_test_tutorial.egg-info/SOURCES.txt'
running build_ext
test_get_area (test.figura_geometrica_test.TestFiguraGeometrico) ... ok
test_get_perimetro (test.figura_geometrica_test.TestFiguraGeometrico) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

Caso apareça uma resposta diferente, dê uma olhada na própria saída do teste. Ele indica onde está o erro. Provavelmente, pode ter sido algum erro de digitação, pois os exemplos deste tutorial foram todos testados.

Criando testes para a classe Quadrado

Vamos criar agora outras classes que realmente fazem algo de útil e seus respectivos testes. Começando pela classe Quadrado, vamos escrever um teste para a mesma no arquivo quadrado_test.py.

# -*- coding: utf-8 -*-fromunittestimportTestCasefromcodigo_avulso_test_tutorial.quadradoimportQuadradoclassTestQuadrado(TestCase):defsetUp(self):TestCase.setUp(self)self.fig=Quadrado()deftest_get_area(self):# Verificamos se o resultado é o esperado# de acordo com a formula de area do quadradoself.fig.lado=2self.assertEqual(self.fig.get_area(),4)self.fig.lado=7.0self.assertEqual(self.fig.get_area(),49.0)deftest_get_perimetro(self):self.fig.lado=2self.assertEqual(self.fig.get_perimetro(),8)self.fig.lado=7.0self.assertEqual(self.fig.get_perimetro(),28.0)

Em seguida, adicionamos o código da classe Quadrado no arquivo quadrado.py:

# -*- coding: utf-8 -*-fromfigura_geometricaimportFiguraGeometricaclassQuadrado(FiguraGeometrica):def__init__(self):self.lado=0# Retorna a area do quadradodefget_area(self):returnself.lado**2# Retorna o perimetro do quadradodefget_perimetro(self):return4*self.lado

Assim como fizemos no exemplo anterior, executamos os testes:

python setup.py test

Se tudo estiver certo, teremos a seguinte saída.

running test
running egg_info
writing codigo_avulso_test_tutorial.egg-info/PKG-INFO
writing top-level names to codigo_avulso_test_tutorial.egg-info/top_level.txt
writing dependency_links to codigo_avulso_test_tutorial.egg-info/dependency_links.txt
reading manifest file 'codigo_avulso_test_tutorial.egg-info/SOURCES.txt'
writing manifest file 'codigo_avulso_test_tutorial.egg-info/SOURCES.txt'
running build_ext
test_get_area (test.quadrado_test.TestQuadrado) ... ok
test_get_perimetro (test.quadrado_test.TestQuadrado) ... ok
test_get_area (test.figura_geometrica_test.TestFiguraGeometrico) ... ok
test_get_perimetro (test.figura_geometrica_test.TestFiguraGeometrico) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.000s

OK

Uma detalhe interessante a ser observado é que agora os testes da classe Quadrado estão sendo executados junto com os testes da classe FiguraGeometrica sem que fosse necessário alterar nenhuma configuração do projeto, ou adicionar algum novo diretório no arquivo setup.py. Isso acontece por que usamos a sufixo _test no nome dos nossos código fonte de teste e também adicionamos o diretório test na tag test_suite no arquivo setup.py. Desse modo, quando executamos os testes, o módulo python Unittest percorre o diretório test, carrega automaticamente todos os arquivos com sufixo _test e executa os testes dentro deles. Bacana não é?

Criando testes para a classe Circulo

Para encerrarmos o tutorial, vamos agora implementar os testes da classe Círculo.

# -*- coding: utf-8 -*-importmathfromunittestimportTestCasefromcodigo_avulso_test_tutorial.circuloimportCirculoclassTestCirculo(TestCase):defsetUp(self):TestCase.setUp(self)self.fig=Circulo()deftest_get_area(self):# Utilizamos a formula diretamente por conveniencia# já que math.pi e double e sendo assim, possui# muitas casas decimaisself.fig.raio=2area=math.pi*self.fig.raio**2self.assertEqual(self.fig.get_area(),area)self.fig.raio=7.0area=math.pi*self.fig.raio**2self.assertEqual(self.fig.get_area(),area)deftest_get_perimetro(self):self.fig.raio=2perimetro=2*math.pi*self.fig.raioself.assertEqual(self.fig.get_perimetro(),perimetro)self.fig.raio=7.0perimetro=2*math.pi*self.fig.raioself.assertEqual(self.fig.get_perimetro(),perimetro)

E agora a classe Circulo:

# -*- coding: utf-8 -*-importmathfromfigura_geometricaimportFiguraGeometricaclassCirculo(FiguraGeometrica):def__init__(self):self.raio=0# Retorna a area do circulodefget_area(self):returnmath.pi*self.raio**2# Retorna o perimetro do circulodefget_perimetro(self):return2*math.pi*self.raio

Finalmente, rodamos os testes agora com a presença da classe circúlo:

python setup.py test

Se tudo estiver certo, teremos a seguinte saída.

running test
running egg_info
writing codigo_avulso_test_tutorial.egg-info/PKG-INFO
writing top-level names to codigo_avulso_test_tutorial.egg-info/top_level.txt
writing dependency_links to codigo_avulso_test_tutorial.egg-info/dependency_links.txt
reading manifest file 'codigo_avulso_test_tutorial.egg-info/SOURCES.txt'
writing manifest file 'codigo_avulso_test_tutorial.egg-info/SOURCES.txt'
running build_ext
test_get_area (test.quadrado_test.TestQuadrado) ... ok
test_get_perimetro (test.quadrado_test.TestQuadrado) ... ok
test_get_area (test.figura_geometrica_test.TestFiguraGeometrico) ... ok
test_get_perimetro (test.figura_geometrica_test.TestFiguraGeometrico) ... ok
test_get_area (test.circulo_test.TestCirculo) ... ok
test_get_perimetro (test.circulo_test.TestCirculo) ... ok

----------------------------------------------------------------------
Ran 6 tests in 0.001s

OK

Conclusão

Com os testes ok, só nos resta subir o código para o github:

git add --all
git commit -m "[NEW] Adicionado classes e testes"
git push origin master

Esse tutorial ficou bem extenso, mas espero que tenha sido útil pra vocês. No próxima parte do tutorial, vamos ver como configurar o Travis, para que ele execute nossos testes quando realizarmos um push ou um pull request para o github. Também veremos o Coveralls que emite relatórios do quando do seu código está coberto por testes, algo muito interessante para ver se um softwareé bem testado.

Os testes que escrevemos foram bem simples, apenas para fim de exemplo. Porém em uma aplicação séria, deve-se ter cuidado na hora de escrever os testes, de maneira a garantir que todas as possibilidades de erros sejam cobertas. A filosofia do TDD de escrever os testes antes do código da nossa aplicação, é algo que exige prática. Eu mesmo ainda não me sinto completamente a vontade seguindo esse fluxo de trabalho. Mas, escrever os testes primeiro te ajuda a manter seu código coerente e funcional, pois vocẽ vai precisar fazê-lo passar pelos testes.

É isso pessoal. Obrigado por ler até aqui. Até a próxima postagem!

Publicado originalmente:python-com-unittest-travis-ci-coveralls-e-landscape-parte-1-de-4