автордың кітабынан сөз тіркестері Путь Python. Черный пояс по разработке, масштабированию, тестированию и развертыванию
logging обеспечивает доступ к встроенной функциональности для логирования;
• multiprocessing позволяет запускать несколько подпроцессов из программы, обеспечивая API, которое представляет их как потоки;
1 Ұнайды
>>> inspect.getgeneratorstate(gen)
❶ 'GEN_CREATED'
>>> next(gen)
1
>>> inspect.getgeneratorstate(gen)
❷ 'GEN_SUSPENDED'
>>> next(gen)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
>>> inspect.getgeneratorstate(gen)
❸ 'GEN_CLOSED'
Это позволяет определить, ждет генератор запуска впервые(GEN_CREATED) ❶, ждет вызова next() для продолжения работы(GEN_SUSPENDED) ❷ или закончил выполнение (GEN_CLOSED) ❸. Это может быть полезным для отладки генераторов.
Еще одно возможное применение для декоратора класса — оборачивание функции или класса другими классами. Например, декоратор класса часто используется для функции-обертки, которая сохраняет состояние. Следующий пример демонстрирует оборачивание функции print() для проверки количества ее вызовов за сессию:
class CountCalls(object):
def __init__(self, f):
self.f = f
self.called = 0
def __call__(self, *args, **kwargs):
self.called += 1
return self.f(*args, **kwargs)
@CountCalls
def print_hello():
print("hello")
Теперь можно использовать ее для проверки количества вызовов функции print_hello():
>>> print_hello.called
0
>>> print_hello()
hello
>>> print_hello.called
1
Листинг 6.10. Вызов методов проверки
>>> from unittest import mock
>>> m = mock.Mock()
❶ >>> m.some_method('foo', 'bar')
<Mock name='mock.some_method()' id='26144272'>
❷ >>> m.some_method.assert_called_once_with('foo', 'bar')
>>> m.some_method.assert_called_once_with('foo', ❸mock.ANY)
>>> m.some_method.assert_called_once_with('foo', 'baz')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/dist-packages/mock.py", line 846, in assert_called_
once_with
return self.assert_called_with(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/mock.py", line 835, in assert_called_
with
raise AssertionError(msg)
AssertionError: Expected call: some_method('foo', 'baz')
Actual call: some_method('foo', 'bar')
Мы создали методы с аргументами foo и bar в качестве тестов, вызвав метод ❶. Простой способ проверить вызовы к объектам-пустышкам — использовать методы assert_called(), такие как assert_called_once_with() ❷. Для этих методов необходимо передать значения, которые, как вы ожидаете, будут использованы при вызове метода-пустышки. Если переданные значения отличаются от используемых, то mock вызывает исключение AssertionError. Если вы не знаете, какие аргументы могут быть переданы, используйте mock.ANY в качестве значения ❸; он заменит любой аргумент, передаваемый в метод-пустышку.
Библиотека mock также может быть использована для замены функции, метода или объекта из внешнего модуля. В листинге 6.11 мы заменили функцию os.unlink() собственной функцией-пустышкой.
Создание метода для объекта mock.Mock с побочным эффектом
>>> from unittest import mock
>>> m = mock.Mock()
>>> def print_hello():
... print("hello world!")
... return 43
...
❶ >>> m.some_method.side_effect = print_hello
>>> m.some_method()
hello world!
43
❷ >>> m.some_method.call_count
1
Мы присвоили целую функцию атрибуту some_method ❶. Технически это позволяет реализовать более сложный сценарий в тесте, благодаря тому что можно включить любой необходимый для теста код в объект-пустышку. Далее нужно передать этот объект в функцию, которая его ожидает.
Атрибут ❷ call_count — это простой способ проверки количества раз, когда метод был вызван.
Библиотека mock использует паттерн «действие — проверка»: это значит, что после тестирования нужно убедиться, что действия, замененные на пустышки, были выполнены корректно.
План нового проекта
Начало нового проекта — та еще задача. Вы еще не знаете, как он будет структурирован, и поэтому могут возникнуть трудности с организацией файлов. Но как только вы поймете, как применить лучшие практики, то сможете определиться, с какой базовой структуры начать. В этом разделе я дам несколько советов, как планировать проект.
Что делать
Для начала рассмотрим структуру проекта: она должна быть как можно более простой. Осторожно используйте пакеты и иерархию: слишком глубокая иерархия затруднит перемещение, а слишком широкая будет неоправданно раздутой.
Избегайте распространенной ошибки по хранению модульных тестов вне директории с пакетом. Эти тесты определенно стоит включить в подпакет вашей программы, чтобы избежать их случайной автоматической установки в виде модуля верхнего уровня tests при использовании setuptools (или аналогичных библиотек разработки пакетов). Размещение их в подпакете гарантирует возможность установки и использования другими пакетами, что позволит остальным пользователям разрабатывать свои собственные модульные тесты.
На рис. 1.2 показана иерархия стандартного файла.
В директории docs должна быть документация о пакете в формате reStructuredText,
В Unix стандартные функции для создания такого событийного цикла — системные вызовы select(2) и poll(2). Эти функции ожидают список дескрипторов и возвращают значение, как только хотя бы один из файловых дескрипторов готов к чтению или записи.
В Python можно получить доступ к этим системным вызовам через модуль select. Построить событийно-ориентированную систему с помощью этих вызовов просто, хотя и утомительно. Листинг 11.3 показывает событийно-ориентированную систему, которая следит за сокетом и обрабатывает любые полученные соединения.
Какие инструменты Вы рекомендуете для профилирования и оптимизации кода?
В Python 3.3 есть функция time.perf_counter() для измерения прошедшего времени в сравнительном тесте. У нее лучшее доступное разрешение.
Тест должен выполняться несколько раз: три раза минимум, пять — более чем достаточно. Повторение теста заполняет кэш диска и процессора. Я предпочитаю поддерживать минимальное время; другие разработчики предпочитают среднее геометрическое.
Для микробенчмарков есть модуль timeit. Он прост в применении и дает быстрые результаты, но они не очень достоверны, если использовать настройки по умолчанию. Тесты придется повторять вручную, чтобы получить устойчивые результаты.
Оптимизация может занять много времени, поэтому лучше сразу сосредоточиться на самых ресурсоемких функциях. Для их поиска в Python есть модули cProfile и profile, фиксирующие время работы каждой функции.