Функционал

Часто в разговоре люди упоминаю Функционал в разрезе функциональных требований/ возможностей системы. Это неправильно.

Оставлю эту ссылку здесь.

pytest BVT часть 2

Как и обещал продолжаю цикл статей про pytest и создание фреймворка для организации BVT.

В прошлой части немного разобрались с терминологией, в этой же более детально опишем, что же будем разрабатывать.

BVT - это базовый набор тестов, который проверяет самое основное, очень часто в это набор уносят тесты, которые проверяют, что называется, целостность сборки. Что будет входить в наш тестовый фреймворк:

1. Проверка наличия файлов. Удобно для проверки бинарных файлов, логов, конфигов, раскиданных по ФС и т.д. и т.п.
2. Запрос версии. У каждого исполняемого файла обязательно должна быть версия или подпись. Почему версия удобна и необходима думаю не нужно говорить.
3. Проверка опций в конфигурационных файлах. Эти проверки избавят от проблем протечки в продакшн конфигов с включенным дебагом. 
4. Статусы запущенных/зарегистрированных сервисов.
5. Проверка статусов запущенных программ.
6. Открытые порты.
7. Проверка ответов на http запросы. Бывает в сервисы встраивают возможность проверки состояния сервисов (а-ля /healthcheck, /check). Удобно проверить и данную функциональность.

На Линуксе подобные проверки легко решаются использованием bash, на github есть замечательный проект https://github.com/sstephenson/bats, который представляет эту возможность из коробки.

Т.к. нашей целью является изучение pytest, то в качестве основы предлагаю взять таверн https://github.com/taverntesting/tavern. Чем он хорош с точки зрения донорского проекта?

1. Декларативный конфиг на yaml. Сама по себе декларация очень удобна, она позволит разделить понятия тестового движка и тестов. Соответственно один человек будет заниматься написанием кода, а другой за наполнение тесового плана. Плюс yaml гораздо удобнее и проще относительно json, xml.
2. Написан на pytest. Можно брать много годных идей, например, cli для прогона тестов.
3. Для фреймворка написаны свои тесты. Да,да, именно тесты. Фреймворки имеют тенденцию с годами расширяться и усложняться, соответственно нужны регрессионные автотесты.
4. Ну и куча других плюше - настроенный gitlab-ci, requirements, документация и т.п.

В следующей части набросаем скелет фреймворка и напишем на нем "hello world".

pytest BVT часть 1

Поговорим немного о тестировании. Что такое Build Verification Test (BVT/БВТ)?

Найти общего определения на просторах интеренета мне не удалось, поэтому попробую свормулировать сам. 

BVT - это набор базовых тестовых сценариев, нацеленных на выявление явных ошибок. Часто в литературе также под BVT понимают Смок или Дымовое тестирование.

BVT обладают следующими свойствами:

1. выполнение тестов производится на каждую сборку
2. высокая скорость исполнение
3. высокое покрытие базовой функциональности
4. включают только критичные тестовые сценарии 

Оговорюсь здесь, что описанные выше свойства довольно условные, каждая команда вправе сама устанавливать критерии качества и расширать BVT до нужного ей объема.

Что все это значит для автоматизатора?

Необходимо написать такие автотесты, которые проверят каждую выпускаемую сборку на соотвествие критичным требованиям. Если у команды есть CI, то на основе прохождения BVT делается заключение о пригодности сборки для дальнейшего тестирования.

Примеры автоматических BVT.

1. Проверка статусов запущенных сервисов.
2. Наличие в сборке исполняемых и конфигурационных файлов.
3. Отсутсвие критичных сообщений об ошибках в логах.
4. и т.п. и т.д.

Разобравшись немного с BVT в следующих частях попробуем написать на pytest небольшой фремворк для разработки универсальных BVT.

Это определение идеально

Есть старый метод исследования систем. Он называется «метод черного ящика». Метод гласит: мы не знаем внутренней структуры системы, но мы можем подать сигнал на ее вход и зафиксировать реакцию на выходе. Сопоставляя определенными методами (методом спектрального анализа, методом решения определенных интегральных уравнений и так далее) функции на входе и выходе, мы можем получить характеристику системы.

pytest продолжение

В первой части статей мы немного познакомились с основными базовыми возможностями pytest. Рассмотрели его особенностей и подходы.

В личных беседах и по почте поступил ряд вопросов и предложений, поэтому продолжению быть. В этой и последующих статьях погрузимся глубже в возможности pytest. Новый материал предлагаю выкладывать в виде поваренной книги - проблема, рецептура, ингредиенты, 5 минут готовки, наслаждение.

Последовательно выполнение тестовых сценариев

В тестировании часто бывают случаи, когда необходимо объединить несколько проверок в один большой тест и выполнить их последовательно. Причем бывает и так, что один сценарий зависит от результатов работы предыдущего (но такое лучше стараться избегать в автотестировании). 

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

Например, тестируемая программа при первом запуске накатывает схему базы (sqlite чтобы не морочиться) и заполняет её некоторой служебной информацией. Допустим перед нами стоит задача "дешево" протестировать этот модуль. Сходу задачу модно разбить на 2 подзадачи - проверка создания файла базы, затем проверка схемы и в конце проверка данных.

Самый простой вариант - нумерация в названии тестов

# conftest.py
import os
import pytest
import sqlite3


def pytest_configure(config):

    config.DB_PATH = "db.sqlite"


@pytest.fixture(scope="module")
def creator(request):
    DB_PATH = request.config.DB_PATH
    con = sqlite3.connect(DB_PATH)
    cur = con.cursor()
    cur.executescript("""
        create table person(
            firstname,
            lastname,
            age
        );

        create table book(
            title,
            author,
            published
        );

        insert into book(title, author, published)
        values (
            'Dirk Gently''s Holistic Detective Agency',
            'Douglas Adams',
            1987
        );
        """)
    con.commit()
    con.close()
    return DB_PATH


@pytest.fixture
def cursor(request):
    class cursor:

        def __init__(self, dbpath):
            self.dbpath = dbpath
            self.conn = sqlite3.connect(self.dbpath)

        def table_exists(self, table):
            cursor = self.conn.cursor()
            cursor.execute(
                "SELECT name FROM sqlite_master WHERE type = \"table\"")
            tables = cursor.fetchall()
            for each in tables:
                if table in each:
                    return True
            return False

        def getrows(self, table):
            cursor = self.conn.cursor()
            cursor.execute("SELECT * FROM %s;" % (table))
            return cursor.fetchall()

    return cursor(request.config.DB_PATH)

# test.py
def test_1_db_exists(creator):
    assert os.path.exists(creator)


@pytest.mark.parametrize("table", ["person", "book"])
def test_2_check_scheme(table, creator, cursor):
    result = cursor.table_exists(table)
    assert result


@pytest.mark.parametrize("table", ["book"])
def test_3_check_rows(table, creator, cursor):
    assert cursor.getrows(table)


Спасибо документации питона за готовые примеры.

У такого подхода есть ряд недостатков.
1. В названии теста появляется нумерация - это лишняя мета информация. (Это может сказаться на тестовом отчете или билд логе CI сервера)
2. Название теста усложняется
3. Вставка нового элемента в середину приведет к смене нумерации всех последующих тестов

Вариант посложнее - маркеры

Свои маркеры мы реализовывать не будем, а используем готовый плагин pytest-ordering. В принципе вся реализация такого плагина составит не больше 100 строчек кода.

# test.py
@pytest.mark.order1
def test_db_exists(creator):
    assert os.path.exists(creator)


@pytest.mark.order2
@pytest.mark.parametrize("table", ["person", "book"])
def test_check_scheme(table, creator, cursor):
    result = cursor.table_exists(table)
    assert result


@pytest.mark.order3
@pytest.mark.parametrize("table", ["book"])
def test_check_rows(table, creator, cursor):
    assert cursor.getrows(table)


Наши тестовые функции преобразились, стали более понимаемы для чтения.
Из коробки плагин содержит создание цепочек выполнения, более понятные маркеры (pytest.mark.run('first'), pytest.mark.run('second')) и прочее. Более подробно в микро доку плагина.

Ссылки
[1] https://docs.python.org/2/library/sqlite3.html
[2] http://pytest-ordering.readthedocs.org/en/develop/

Топ 10 вопросов по python на stackoverflow

What does the yield keyword do in Python?
What is a metaclass in Python?
How to check whether a file exists using Python
Does Python have a ternary conditional operator?
Calling an external command in Python
How can I make a chain of function decorators in Python?
What does `if __name__ == “__main__”:` do?
How can I merge two Python dictionaries in a single expression?
Sort a Python dictionary by value
How do I install pip on Windows?

Довольно ожидаемо

[1] stackoverflow.com

Годная презентация по pytest

Годная презентация по pytest от Андрея Светлова pytest-slides

Пара годных практик

Instead of writing methods without return values, make them return self

# Instead of this
self.release_water()
self.shutdown()
self.alarm()

class Reactor:
    ...
    def release_water(self):
        self.valve.open()
        return self

self.release_water().shutdown().alarm()   

Enumeration (iteration) method

# Bad
# Can't change type of collection
#     e.g. can't change employees from a list to a set
class Department:
    def __init__(self, *employees):
        self.employees = employees

for employee in department.employees:
    ...
   
# Better
class Department:
    def __init__(self, *employees):
        self._employees = employees

    def __iter__(self):
        return iter(self._employees)

for employee in department:  # More readable, more composable

Оригинал старьи

exrex генератор данных по регулярным выражениям

Всем привет!

На просторах гитлаба наткнулся на небольшую библиотеку exrex, позволяющую генерировать данные по регулярным выражениям.

API крайне простой
count - возвращет количество возможных вариаций
parse - парсер регулярных выражений
getone - возвращает псевдо-рандомное значение
generate - возвражает генератор со всеми вариантами

Примеры использования

На всякий замечу, что у вас по некоторым примером вывод может быть другим

>>> print exrex.getone('[A-Z][a-z]{1,10} [A-Z][a-z]{1,10}')
Boris Yeltsin

>>> print exrex.getone('\+[0-9]\([0-9]{3}\) [0-9]{3}-[0-9]{2}-[0-9]{2}')
+5(777) 790-68-69

>>> print [r for r in exrex.generate('|'.join(str(i) for i in range(5)))]
[u'0', u'1', u'2', u'3', u'4']

>>> exrex.count('[0-9]{1}')
10

>>> print exrex.parse('[0-9]{1,100}')
[('max_repeat', (1, 100, [('in', [('range', (48, 57))])]))]

Есть также возможность запуска из консоли

>>> python -m exrex -r [0-9]{2}
31
Возвращает псевдо-рандомное число из 2 цифр

За более подробной информацией в ссылки.

Ссылки

https://github.com/asciimoo/exrex
http://exrex.readthedocs.org/

Список дизасемблеров для питона

Неплохой список дизасемблеров для питона http://pythonarsenal.erpscan.com/

python кодировка исходников

Всем привет!

Я думаю каждый из нас ловил что-то подобное:

 File "python_coding_style.py", line 2
SyntaxError: Non-ASCII character '\xd0' in file python_coding_style.py on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

Проблема в том что интерпретатор не знает в какой кодировке у нас файлы исходников. Проблема решается явным указанием их кодировки:
# coding: utf8

Чаще на практике встречаются следующие варианты

# -*- coding: utf8 -*-
# coding: utf8
# coding=utf8

В PEP-0263 декларируется, что для определения кодировки исходников годится все что подпадет под регулярку coding[:=]\s*([-\w.]+)
Например, #This Python file uses the following encoding: utf-8 !!!

Ссылки

http://legacy.python.org/dev/peps/pep-0263/

Часть 4. py.test debug

Мы уже рассмотрели основные принципы написание тестов, но один важный момент упустили, а именно дебаг тестов.

Использование print

Часто люди пользующие питон дебажат свои скрипты с помощью использования принтов. По умолчанияю pytest пишет весь stout и stderr. В предыдущем посте эта тема рассматривалась. Для отключения этой особенности нужно использовать параметр --capture или маску -s. 
Посмотрим на небольшой (надуманный) пример:

# use_debug.py
@py.test.mark.parametrize("v", range(1, 5))
def test_parity(v):
    print("Value: %d" % v)
    assert v % 2

>>>py.test use_debug.py -s -v --tb line

============================= test session starts =============================
platform win32 -- Python 2.7.5 -- py-1.4.20 -- pytest-2.5.2 -- C:\Python27\python.exe
plugins: teamcity-messages, rerunfailures
collected 4 items

use_debug.py:40: test_parity[1] Value: 1
PASSED
use_debug.py:40: test_parity[2] Value: 2
FAILED
use_debug.py:40: test_parity[3] Value: 3
PASSED
use_debug.py:40: test_parity[4] Value: 4
FAILED

================================== FAILURES ===================================
c:\JOB\3_TestSolution\Blog\use_debug.py:43: assert (2 % 2)
c:\JOB\3_TestSolution\Blog\use_debug.py:43: assert (4 % 2)
===================== 2 failed, 2 passed in 0.03 seconds ======================

Как видим в консоли напечатались входные значения. 

Автовключение дебага

Для этого предусмотрен флаг --pdb. Если тест пофелился, то py.test прогонит его на тех же данных, но уже с включенным питоновским дебагером pdb.

>>>py.test use_debug.py -s -v --tb line --pdb

platform win32 -- Python 2.7.5 -- py-1.4.20 -- pytest-2.5.2 -- C:\Python27\python.exe
plugins: teamcity-messages, rerunfailures
collected 4 items

use_debug.py:64: test_parity[1]
>>>>>>>>>>>>>>>>>>> PDB set_trace (IO-capturing turned off) >>>>>>>>>>>>>>>>>>>
> c:\job\3_testsolution\blog\use_debug.py(67)test_parity()
-> assert v % 2
(Pdb)

Брейкпоинты

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

# use_debug.py
@py.test.mark.parametrize("v", range(1, 5))
def test_parity(v):
    py.test.set_trace()
    assert v % 2

При каджом вызове тестовой функции test_parity в месте устанвки брейкпоинта py.test будет запускать pdb

>>>py.test use_debug.py -s -v --tb line

use_debug.py:62: test_v[1]
>>>>>>>>>>>>>>>>>>> PDB set_trace (IO-capturing turned off) >>>>>>>>>>>>>>>>>>>
> c:\job\3_testsolution\blog\use_debug.py(65)test_v()
-> assert v % 2
(Pdb)

Ссылки

http://pytest.org/latest/usage.html#dropping-to-pdb-python-debugger-on-failures
http://pytest.org/latest/usage.html#setting-a-breakpoint-aka-set-trace

python copy/deepcopy

Всем привет!

Продолжаем ломать копья об питоновскую парадигму изменяемых/неизменяемых объектов.
Разберем поверхностное и глубокое копирование словаря.

>>>s = {"str": "1", "list": [1, 2], "dict": {"first": "test1"}}
>>>f = s
>>>f['second'] = '2'

>>>print s

Надеюсь понятно какой вывод будет в консоли. Если нет, то смотрим ссылки.
Для того чтобы не ссылаться на один объект, нужно скопировать словарь s.

Но метод copy обладает неприятной особенностью, он поверхностно копирует словарь.
Смотрим на пример (s из предыдущего примера).

>>>f = s.copy()
>>>f['second'] = '3'
>>>f['dict']['third'] = '3'
>>>print s

{'dict': {'third': '3', 'first': 'test1'}, 'list': [1, 2], 'str': '1'}

Проблема решается использованием модуля copy.

>>>import copy

>>>f = copy.deepcopy(s)
>>>f['second'] = '3'
>>>f['dict']['third'] = '3'
>>>print s

>>>print f

Как работает copy.deepcopy

Начнем с аргументов

deepcopy(x, memo=None, _nil=[])

x - копируемый объект. Копируемым объектом может быть любой стандартный тип данных, а также кастомных объектов.
memo - словарь, в котором будут сопоставлены id созданных объектов и их значения. По-умолчанию None(если не понятно почему, то смотрим в ссылки [3]). При желании можно реализовать собственный "копир", если есть потребность в специфичном поведении копирования.
_nil - вспомогательный атрибут, используемый во время копирования

Пара примеров для понимания работы deepcopy

>>>s = {"i": 1, "s": "2", "l": [1, 2, 3]}
>>>memo = {}
>>>d = copy.deepcopy(s, memo)

>>>print id(s)
44501728

>>>print id(d)
44502304

>>>print d
{'i': 1, 's': '2', 'l': [1, 2, 3]}

>>>print id(memo)
44502016

>>>print memo

{44501728: {'i': 1, 's': '2', 'l': [1, 2, 3]}, 31711104: '2', 31565540: 2, 44502016: [1, 'i', '2', 's', 2, 3, [1, 2, 3], 'l', {'i': 1, 's': '2', 'l': [1, 2, 3]}], 31266408: 'i', 31565552: 1, 31565528: 3, 31268304: 's', 31708488: 'l', 44497976: [1, 2, 3]}

Словарь memo хранит id всех копируемых объектов, их значения., а также свой id.

>>>dt = copy.deepcopy(s, memo)

>>>print id(dt)
44502304

print dt
{'i': 1, 's': '2', 'l': [1, 2, 3]}

Как видим, deepcopy возвращает уже копировавшийся объект d

>>>s1 = {"i": 1, "s": "2", "l": [1, 2, 3]}
>>>dth = copy.deepcopy(s1, memo)
>>>print id(s1)
44516240

>>>print(id(dth))
44517248

>>>print(dth)
{'i': 1, 's': '2', 'l': [1, 2, 3]}

>>>print(id(memo))
44502016

>>>print(memo)
{44501728: {'i': 1, s': '2', 'l': [1, 2, 3]}, 31711104: '2', 44516240: {'i': 1,  's': '2', 'l': [1, 2, 3]}, 31565540: 2, 44502016: [1, 'i', '2', 's', 2, 3, [1, 2, 3], 'l', {'i': 1, 's': '2', 'l': [1, 2, 3]}, [1, 2, 3], {'i': 1, 's': '2', 'l': [1, 2, 3]}], 31266408: 'i', 31565552: 1, 31565528: 3, 44498856: [1, 2, 3], 31268304: 's', 31708488: 'l', 44497976: [1, 2, 3]}

Реализация deepcopy

Сначала происходит инициализация memo, если словарь не задан. Если memo задан тогда проверяется наличие id копируемого объекта, если такой объект уже есть в memo, то происходит его возврат.

d = id(x)
y = memo.get(d, _nil)
if y is not _nil:
    return y

Т.е. если после копирования нужно все время получать новый объект, то тогда поле memo нужно оставлять по-умолчанию (это мы видели на примере выше).

Далее определяется тип копируемого объекта и если он есть в описании стандартных типов, то вызывается функция копирования

copier = _deepcopy_dispatch.get(cls)
if copier:
    y = copier(x, memo)

Например, для словаря вызывается _deepcopy_dict

def _deepcopy_dict(x, memo):
    y = {}
    memo[id(x)] = y
    for key, value in x.iteritems():
        y[deepcopy(key, memo)] = deepcopy(value, memo)
    return y

Код довольно простой, создается новый словарь, в цикле копируются значения. Обратите внимание копирование идет - рекурсивным вызовом deepcopy, сделано это на случай того, если словарь составной и содержит вложенные объекты.
После успешного копирования обновляется словарь memo и вызывается функция _keep_alive, которая записывает в memo, сам копируемый объект, т.е. если вызвать memo[id(memo)], то получим список всех объектов, которые копировались.

Ссылки
[1]https://docs.python.org/2/library/stdtypes.html#dict.copy
[2]https://docs.python.org/2/library/copy.html
[3]http://evgenqa.blogspot.ru/2014/05/blog-post_23.html

serchcode

Для тех кто в танке и не читает хабр прикольный поисковик по коду опен сорс https://searchcode.com/


Нашел 193 результата по запросу putIn и 760 по medveDev.

The Architecture of Open Source Applications

http://aosabook.org/en/index.html - неплохие статьи об архитекруре приложений с открытым исходным кодом. git, mercurial, nginx, zeromq и проч. А также есть что почитать для тех кто пишет на питоне - Twisted, SQLAlchemy.

Часть 3. Совсем немного о py.test.exe

py.test.exe это тул призванный упростить запуск тестов. Оговорюсь сразу что в мою задачу не входит перевод документации, поэтому ознакомится с полным набором команд можно, выполнив в командной строке следующую комманду (да и он может различаться в зависимости от того какие установлены плагины) и пройти по сслылкам в конце поста.

>>> py.test -h

Команды формирования вывода

-q - уменьшает детализацию информации о выполнении теста

-v - увеличивает детализацию о выполнении теста

--capture - параметр для управлением захвата вывода stdout/stderr. Принимает одно из значений fd|sys|no. Более подробно в ссылках
-s - маска для --capture=no. Параметр удобен, если нужно убрать мусор (например, дебажные принты) из информации о выполнившихся тестах.

--tb - отвечает за детализацию вывода трейса. Одно из long/short/line/native/no

Команды запуска 

-k <test name> - выполнить лишь заданный тест

--maxfail=<fail count> - задает максимальное число фейлов, тест удобен при дебаге или если заранее известно что результат тестов будет один и тотже
-x - маска дял --maxfaile=1

--pdb - стартует питоновский дебагер для отладки ошибок. Удобен для отладки тестов (подробнее в одном из следующих постов о дебаге тестов)

Комманды для настройки

--color (yes|no|auto) - цветной вывод в консоли или нет

Совсем небольшой пример

# use_tool.py
import py.test

@py.test.mark.parametrize('num', [i for i in range(5)])
def test_func(num):
    print('\ntest_func()')
    assert num % 2

def test_fail():
    print('bla, bla, fail')
    assert False

Выполняем в консоли
>>>py.test use_tool.py -k "test_func" -v -s -x --tb=line

============================= test session starts =============================
platform win32 -- Python 2.7.5 -- py-1.4.20 -- pytest-2.5.2 -- C:\Python27\python.exe
plugins: teamcity-messages
collected 6 items

use_tool.py:37: test_func[0]
test_func()
FAILED

================================== FAILURES ===================================
use_tool.py:40: assert (0 % 2)
!!!!!!!!!!!!!!!!!!! Interrupted: stopping after 1 failures !!!!!!!!!!!!!!!!!!!!
===================== 1 tests deselected by '-ktest_func' =====================
=================== 1 failed, 1 deselected in 0.04 seconds ====================

Ссылки

[1] http://pytest.org/latest/capture.html
[2] http://pytest.org/latest/customize.html?highlight=maxfail
[3] http://pytest.org/latest/usage.html

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

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

Что такое test fixtures

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

setup/teardown

Часто перед запуском теста нужно провести базовые подготовления. Например, это может быть настройка окружения, запуск тестовых сервисов, подготовка тестовых данных, инициализация соединения с базами и проч. Для выполнения этих операций в py.test входит небольшой набор вспомогательных функций - несколько пар setup/teardown.

setup_module(module)
teardown_module(module)

Это функции которые вызываются перед и после выполнения всех тестов (в прошлой части более подробно об организации тестов)
Данную пару удобно использовать когда подготовка флоу происходит однажды - перед  запуском всех тестов.

setup_function(function)
teardown_function(function)

Делают тоже самое что и предыдущие функции, с единственным исключением - функции вызываются перед/после каждым выполнением всех тестовых сценариев. 
Рассмотрим небольшой надуманный пример, для понимания механизма

#fixtures.py
def setup_module(module):
    print('\nsetup_module()')


def teardown_module(module):
    print('\nteardown_module()')


def setup_function(function):
    print('\nsetup_function()')


def teardown_function(function):
    print('\nteardown_function()')


def test_first():
    print('\ntest_first()')


def test_second():
    print('\ntest_second()')


class TestMyClass:
    @classmethod 
    def setup_class(cls):
        print ('\nsetup_class()')

    @classmethod 
    def teardown_class(cls):
        print ('teardown_class()')

    def setup_method(self, method):
        print ('\nsetup_method()')

    def teardown_method(self, method):
        print ('\nteardown_method()')

    def test_first(self):
        print('test_first()')

    def test_second(self):
        print('test_second()')



>>>py.test -s -v fixtures.py

============================= test session starts =============================
platform win32 -- Python 2.7.5 -- py-1.4.20 -- pytest-2.5.2 -- C:\Python27\python.exe
collected 4 items

fixtures.py:17: test_first
setup_module()

setup_function()

test_first()
PASSED
teardown_function()

fixtures.py:21: test_second
setup_function()

test_second()
PASSED
teardown_function()

fixtures.py:40: TestMyClass.test_first
setup_class()

setup_method()
test_first()
PASSED
teardown_method()

fixtures.py:43: TestMyClass.test_second
setup_method()
test_second()
PASSED
teardown_method()
teardown_class()

teardown_module()
========================== 4 passed in 0.02 seconds ===========================

Встроенные фикстуры

В py.test предусмотрен обширный набор встроенных фикстур с полным набором можно ознакомиться, выполнив в консоле следующую команду

>>>py.test --fixtures

Для ознакомления в данном посте рассмотри одну из встроенных фикстур tempdir
temdir
Очень полезная вещь, предназначена для работы с темповыми данными. Т.е. в темповой директории можно хранить любые временные файлы. Например, это могут быть логи тестируемых программ или какой-то контекcт теста, который может понадобиться для воспроизведения бага.

Использовать крайне просто

#fixtures.py
def test_file(tmpdir):
    f = tmpdir.mkdir('logs').join('test.log')
    print(tmpdir.strpath)
    f.write('bla bla')

    with open(f.strpath, 'r') as fp:
        print(fp.read())

>>>py.test -s -v fixtures.py
============================= test session starts =============================
platform win32 -- Python 2.7.5 -- py-1.4.20 -- pytest-2.5.2 -- C:\Python27\python.exe
collected 1 items

fixtures.py:161: test_file \temp\pytest-76\test_file0
bla bla
PASSED

========================== 1 passed in 0.03 seconds ===========================

Полезные фикстуры

Для итерации по входным данным можно использовать полезный декоратор py.test.mark.parametrize

#fixtures.py
@py.test.mark.parametrize('num', [i for i in range(2)])
def test(num):
    assert num % 2

py.test -s -v fixtures.py

============================= test session starts =============================

platform win32 -- Python 2.7.5 -- py-1.4.20 -- pytest-2.5.2 -- C:\Python27\python.exe

collected 2 items

fixtures.py:182: test[0] FAILED

fixtures.py:182: test[1] PASSED

================================== FAILURES ===================================

___________________________________ test[0] ___________________________________

num = 0

    @py.test.mark.parametrize('num', [i for i in range(2)])

    def test(num):

>       assert num % 2

E       assert (0 % 2)

fixtures.py:184: AssertionError

===================== 1 failed, 1 passed in 0.02 seconds ======================

Кастомизация

О кастомных фикстурах более подробно в одном из следующих постов, поэтому здесь совсем небольшой пример.

Для определения собственных инструментов в py.test предусмотрены 

#fixtures.py
@pytest.fixture(scope="function")
def before(request):
    print('\nbefore()')

    def after():
        print("\nafter()")
    request.addfinalizer(after)


def test_func(before):
    print("\ntest_func()")



>>>py.test -s -v fixtures.py
============================= test session starts =============================
platform win32 -- Python 2.7.5 -- py-1.4.20 -- pytest-2.5.2 -- C:\Python27\python.exe
collected 1 items

fixtures.py:14: test_func
before()

test_func()
PASSED
after()
========================== 1 passed in 0.01 seconds ===========================

Вывод

1. Прежде всего это создано для удобства (как собственно и весь py.test)
2. Сокращает время разработки теста
3. делает тест прозрачнее
4. Уменьшает количество копипаста

Ссылки

http://pytest.org/latest/
http://en.wikipedia.org/wiki/Test_fixture
http://pythontesting.net/

Понимаем 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 “<stdin>”, line 1, in <module>
  File “<stdin>”, line 8, in func_1
  File “<stdin>”, 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

изменяемый объект в аргументах

Тема замусолена до невозможности, но не удержался увидев код Request

def func(f, l=[]):
    l.append(f)
    return l

func является потенциально опасной. Смотрим что происходит при её использовании

>>> print(func(1))
[1]
>>> print(func(2))
[1, 2]


l ссылается на один и тот же объект, который все время и изменяется (вспоминаем концепцию python)

Решение очевидное - определить список в функции

Такое решение используется и в популярном фреймворке request

class Request(RequestHooksMixin):
    def __init__(self,
        method=None,
        url=None,
        headers=None,
        files=None,
        data=None,
        params=None,
        auth=None,
        cookies=None,
        hooks=None):

        # Default empty dicts for dict params.
        data = [] if data is None else data
        files = [] if files is None else files
        headers = {} if headers is None else headers
        params = {} if params is None else params
        hooks = {} if hooks is None else hooks

Ссылки

https://github.com/kennethreitz/requests/blob/master/requests/models.py