Архив рубрики: Python

Часть 2. Фикстуры pytest

Всем привет

В первой части немного познакомились с фреймворком для тестирования py.test, а в этой немного углубимся и посмотрим на дополнительные инструменты py.test.

Что такое test fixtures

В тестировании обычно под этим понимают флоу теста, его контекст.
В py.test предусмотрены следующие типы фикстур: встроенные фикстуры, вспомогательные функции, декораторы

Читать

Часть 1. pytest. Первый взгляд

Каждый девелопер, для которого слова tdd, unittest, ci являются не пустыми, слышал про тестовый фраймворк pytest (он же py.test). По каким-то причинам этот тестовый фраймвор слабо освещен на просторах рунета. В ряде статей постараюсь заполнить этот пробел. Думаю, познакомившись с pytest поближе вы забудете про стандартный unittest.



Преимущества pytest

  • он простой
  • он функциональный, в коробке идет большое количество киллер фич
  • он логичный
  • он расширяемый
  • он умный, можно запускать тесты на unittest, doctest
  • код тестов меньше и проще

Ставим


pip install -U pytest
Или через easy_install
easy_install -U pytest

Или из пакета
Качаем пакет http://pypi.python.org/pypi/pytest

python pytest/setup.py install

Единственно при оффлайн установке стоит учесть что для работы pytest нужно еще 2 пакета — colorama и py

Пробуем


Забегая в перед скажу что все тестовые функции должны начинаться с префикса test_*.

# tests.py
def test_first_our_passed():
    assert True

def test_first_our_failed():
    assert False

Запустим тест в консоли py.test test.py

============================= test session starts =============================
platform win32 — Python 2.7.5 — py-1.4.20 — pytest-2.5.2
collected 2 items

tests_first.py .F

================================== FAILURES ===================================
____________________________ test_first_our_failed ____________________________

    def test_first_our_failed():
>       assert False
E       assert False

tests_first.py:6: AssertionError
===================== 1 failed, 1 passed in 0.13 seconds ======================

Из коробки получаем довольно информативный вывод


Структура проекта


Есть два устоявшихся принципа по организации тестового проекта
Все тесты находятся в папке test рядом с пакетами проекта

/myproj
    __init__.py
    project.py
/test
    test_func_1.py
    test_func_2.py

Второй вариант — папка с тестами находится в самом пакете проекта

/myproj
    __init__.py
    project.py
    /test
        test_func_1.py
        test_func_2.py

Разница не большая, а скорее дело вкуса.


Структура тестов


В принципа здесь все банально. Для рассмотрения будем использовать простой тестовый проект.

/myproj
    __init__.py
    project.py

# project.py
def pp(val):
    return val + 1

Первый принцип — все тесты описаны в виде тестовых функциях

def test_positive():
    assert pp(1) == 2

def test_negative():
    assert pp(1) == 1

Второй принцип — все тесты описаны в виде методов тестового класса

class TestProject:
    def test_positive(self):
        assert pp(1) == 2

    def test_negative(self):
        assert pp(1) == 1

На тестах данные принцип практически не сказывается.

Варианты запуска

Из коробки в pytest предусмотрено несколько вариантов запуска тестов.

Через специальную утилиту py.test.exe

py.test.exe test_project.py

В консоли через питон 

python -m «pytest.main('test directory')»

Вызов pytest в коде

if __name__ == '__main__':
    pytest.main('test_project.py')

+ никто не отменял сабпроцесс;)

Ссылки

http://pytest.org

Автор: Евгений Курочкин

Понимаем UnboundLocalError

Опять же на programmingwats.tumblr.com наткнулся на небольшую особенность питона.

my_str_1 = «1: outside of func»
my_str_2 = «2: outside of func»
def func_1():
    my_str_1 = «1: inside the func»
    my_str_2 = «2: inside the func»
    def func_2():
        print(my_str_1)
        print(my_str_2)
        my_str_1 = «1: inside the class»
    func_2()

func_1()
prints:
Traceback (most recent call last):
  File “”, line 1, in
  File “”, line 8, in func_1
  File “”, line 5, in func_2
UnboundLocalError: local variable ‘my_str_1’ referenced before assignment

В принципе на эту тему написано довольно много постов и погуглив можно спокойно найти объяснение. Но т.к. в свое время эта особенность питона попила у меня много кровушки я решил написать небольшой пост.

В чем причина такого поведения?
Причина заключается в том что питон преобразует переменную my_str_1 в локальную для func_2 и во время вызова функции print получает на вход не инициализированную переменную.
Решения проблемы тривиальные — либо убрать print, либо изменить название переменной, или объявить my_str_1 как глобальную.

Кто хочет более подробно ознакомиться с причинами такого поведения см ссылки, особенно с [2]

Ссылки

[1]https://docs.python.org/2/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value
[2]http://eli.thegreenplace.net/2011/05/15/understanding-unboundlocalerror-in-python/
[3]http://programmingwats.tumblr.com/page/2

Автор: Евгений Курочкин

python 2 утечка переменных цикла

Проглядывая programmingwats.tumblr.com нашел небольшую особенность python 2.

Посмотрим на пример:

>>>x = «top»
>>>print(list(«a» for x in (1,2)), x)
>>>print([«a» for x in (1,2)], x)

([‘a’, ‘a’], ‘top’)
([‘a’, ‘a’], 2)

Это бага питона, связанная с тем что локальная переменная x, используемая при создании списка становилась доступной в родительском пространстве имен. Думаю понятно чем грозит данная бага.
Данная бага поправлена в python 3.

Ссылки

https://docs.python.org/3/whatsnew/3.0.html#changed-syntax
http://programmingwats.tumblr.com/page/2
http://nbviewer.ipython.org/github/rasbt/python_reference/blob/master/tutorials/key_differences_between_python_2_and_3.ipynb?create=1

Автор: Евгений Курочкин

Когда использовать import

И так, в предыдущем посте, было рассказано о минусах инструкции from и о том, что использование import более надежней и практичней. Поэтому речь пойдет о использовании import.


Единственное,  когда  необходимо  вместо  инструкции  from  использовать  инструкцию import, – когда требуется использовать одно и то же имя, присутствующее в двух разных модулях. Например, когда два файла по-разному определяют одно и то же имя:
# M.py

def func():
    …выполнить что-то одно…

# N.py

def func():
    …выполнить что-то другое…
и необходимо использовать обе версии имени в программе. В этом случае инструкцию from использовать нельзя, потому что в результате вы получите единственное имя в вашей области видимости:
# O.py

from M import func
from N import func     # Перезапишет имя, импортированное из модуля M
func()                 # Будет вызвана N.func
Зато  можно  использовать  инструкцию  import,  потому  что  включение  имени

вмещающего модуля сделает имена уникальными:

# O.py
 
import M, N    # Получить модуль целиком, а не отдельные имена
M.func()       # Теперь можно вызывать обе функции
N.func()       # Наличие имени модуля делает их уникальными
Этот случай достаточно необычен, поэтому вы вряд ли часто будете сталкиваться с ним на практике. Но если такая ситуация все-таки возникнет, инструкция import позволит вам избежать конфликта имен.
Фух, за день две статьи, спасибо за подписи, надеюсь количество увеличиться и увеличится количество статей. Ставим + , приглашаем друзей и комментируйте записи.

Автор: Няшный Человек
Дата публикации: 2014-05-25T11:42:00.002+03:00

Минусы инструкции from

Здравствуйте читатели. Ну что, вот вам еще очередная порция текста по программированию используя Python )
На этот раз речь пойдет о минусах использовании инструкции from.




 — У инструкции from менее явное отображение переменной (имя name несет меньше информации, чем module.name), поэтому некоторые пользователи Python  рекомендуют  использовать  инструкцию  import  вместо from. Но это иногда можно опровергнуть, так как такой использование from происходит довольно таки часто и без страшных последствий.

 — Инструкция from способна повреждать пространства имен, по крайней мере, в принципе – если использовать ее для импортирования переменных, когда существуют одноименные переменные в имеющейся области видимости, то эти переменные просто будут перезаписаны. Эта проблема отсутствует при использовании инструкции import, потому что доступ к содержимому импортируемого модуля возможен только через его имя (имя module.attr не конфликтует с именем attr в текущей области видимости). 
Пока вы понимаете и контролируете все, что может происходить при использовании инструкции from, во всем этом нет большой проблемы, особенно если импортируемые имена указываются явно (например, from module import x, y, z).

С другой стороны, инструкция from скрывает в себе более серьезные проблемы, когда используется в комбинации с функцией reload, так как импортированные имена могут ссылаться на предыдущие версии объектов. Кроме того, инструкция в форме from module import * действительно может повреждать пространства имен и затрудняет понимание имен, особенно когда она применяется более чем к одному файлу, – в этом случае нет никакого способа определить, какому модулю принадлежит то или иное имя, разве только выполнить поиск по файлам с исходными текстами. В действительности форма from * вставляет одно пространство имен в другое, что сводит на нет преимущества, которые несет возможность разделения пространств имен.

Пожалуй, лучший совет, который можн