Testando seu código¶

Testar o seu código é muito importante.

Getting used to writing testing code and running this code in parallel is nowconsidered a good habit. Used wisely, this method helps to define yourcode’s intent more precisely and have a more decoupled architecture.

Algumas regras gerais de teste:

• Uma unidade de teste deve se concentrar em um pequeno número de funcionalidades e provar que tudo está correto.
• Cada unidade de teste deve ser totalmente independente. Cada teste deve ser capaz de executar sozinho, e também dentro do conjunto de teste, independentemente da ordem em que são chamados. A implicação desta regra é que cada teste deve ser carregado com um novo conjunto de dados e talvez seja necessário fazer alguma limpeza depois. Isso geralmente é gerenciado pelos métodossetUp() etearDown().
• Tente arduamente fazer testes que funcionem rapidamente. Se um único teste precisa de mais de alguns milissegundos para executar, o desenvolvimento será diminuído ou os testes não serão executados com a frequência desejável. Em alguns casos, os testes não podem ser rápidos porque eles precisam de uma estrutura de dados complexa para trabalhar, e esta estrutura de dados deve ser carregada toda vez que o teste é executado. Mantenha esses testes mais pesados em um conjunto de teste separado executado por alguma tarefa agendada e execute todos os outros testes sempre que necessário.
• Aprenda suas ferramentas e aprenda como executar uma única prova ou um caso de teste. Então, ao desenvolver uma função dentro de um módulo, execute os testes dessa função freqüentemente, idealmente automaticamente quando você salvar o código.
• Execute sempre o conjunto de teste completo antes de uma sessão de codificação, e execute novamente depois. Isso lhe dará mais confiança de que você não quebrou nada no resto do código.
• É uma boa ideia implementar um hook que executa todos os testes antes de enviar o código para um repositório compartilhado.
• Caso estejas no meio de uma sessão de desenvolvimento e tiver que interromper o seu trabalho, é uma boa ideia escrever um teste de unidade quebrado sobre o que deseja desenvolver em seguida. Ao retornar ao desenvolvimento, você terá um ponteiro para onde estavas e voltará ao percurso mais rapidamente.
• O primeiro passo quando você estiver depurando o seu código é escrever um novo teste identificando o bug. Embora nem sempre seja possível, esses testes de detecção de falhas estão entre os mais valiosos itens de código do seu projeto.
• Use nomes longos e descritivos para testar funções. O guia de estilo aqui é ligeiramente diferente do código de execução, onde os nomes curtos são frequentemente preferidos. O motivo é que as funções de teste nunca são chamadas explicitamente.square() ou mesmosqr() está ok no código em execução, mas no código de teste você teria nomes comotest_square_of_number_2(),test_square_negative_number(). Esses nomes de função são exibidos quando um teste falhar e deverá ser o mais descritivo possível.
• When something goes wrong or has to be changed, and if your code has agood set of tests, you or other maintainers will rely largely on thetesting suite to fix the problem or modify a given behavior. Thereforethe testing code will be read as much as or even more than the runningcode. A unit test whose purpose is unclear is not very helpful in thiscase.
• Another use of the testing code is as an introduction to new developers. Whensomeone will have to work on the code base, running and reading the relatedtesting code is often the best thing that they can do to start. They willor should discover the hot spots, where most difficulties arise, and thecorner cases. If they have to add some functionality, the first step shouldbe to add a test to ensure that the new functionality is not already aworking path that has not been plugged into the interface.

importunittestdeffun(x):returnx+1classMyTest(unittest.TestCase):deftest(self):self.assertEqual(fun(3),4)

defsquare(x):"""Return the square of x.    >>> square(2)    4    >>> square(-2)    4    """returnx*xif__name__=='__main__':importdoctestdoctest.testmod()

$ pip install pytest

# content of test_sample.pydeffunc(x):returnx+1deftest_answer():assertfunc(3)==5

$ py.test=========================== test session starts ============================platform darwin -- Python 2.7.1 -- pytest-2.2.1collecting ... collected 1 itemstest_sample.py F================================= FAILURES =================================_______________________________ test_answer ________________________________    def test_answer():>       assert func(3)==5E       assert 4 == 5E        +  where 4 = func(3)test_sample.py:5: AssertionError========================= 1 failed in 0.02 seconds =========================

$ pip install hypothesis

@given(lists(floats(allow_nan=False,allow_infinity=False),min_size=1))deftest_mean(xs):mean=sum(xs)/len(xs)assertmin(xs)<=mean(xs)<=max(xs)

Falsifying example: test_mean(    xs=[1.7976321109618856e+308, 6.102390043022755e+303])

$ pip install tox

$ pip install mock

frommockimportMagicMockthing=ProductionClass()thing.method=MagicMock(return_value=3)thing.method(3,4,5,key='value')thing.method.assert_called_with(3,4,5,key='value')

defmock_search(self):classMockSearchQuerySet(SearchQuerySet):def__iter__(self):returniter(["foo","bar","baz"])returnMockSearchQuerySet()# SearchForm here refers to the imported class reference in myapp,# not where the SearchForm class itself is imported from@mock.patch('myapp.SearchForm.search',mock_search)deftest_new_watchlist_activities(self):# get_search_results runs a search and iterates over the resultself.assertEqual(len(myapp.get_search_results(q="fish")),3)