rf тест доска — купите rf тест доска с бесплатной доставкой на АлиЭкспресс version

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

* # * # 225 # * # * – Календарь событий.

* # * # 759 # * # * – Доступ к настройке партнера Google (интерфейс отладки Rlz).

* # 872564 # – Управление протоколом USB.

* # 9900 # – Режим системного дампа Huawei Honor 6A.

* # * # 97 # * # * – Настройки языка и клавиатуры в Huawei Honor 6A.

* # * # 46 * # * # – Сброс Sim в Huawei Honor 6A.

* # 301279 # – HSDPAHSDPA означает «Высокоскоростной пакетный доступ по нисходящейлинии связи» и является методом, используемым в системе мобильной связи UMTS,скоростью загрузки от 3,6 Мбит / с до 7,2 Мбит / с. HSUPA разрабатывается коммерческис 2007 года в Германии. Высокоскоростной пакетный доступ по нисходящей линиисвязи (HSDPA, 3.

5G, 3G или широкополосный UMTS) является методом передачи данныхсотовых стандартов UMTS, который был определен проектом партнерства третьего поколения.Этот метод позволяет DSL-подобные скорости передачи данных в мобильных сетях.HSDPA доступен в Германии, среди прочего, сетевыми операторами Vodafone, E-Plus,O2 и телекоммуникационными компаниями, а также в Швейцарии Swisscom, Sunrise иOrange.

В Австрии работают сети A1, T-Mobile, Orange и Three HSDPA./ HSUPAHSUPAозначает «Высокоскоростной пакетный доступ по восходящей линии» и является методом,используемым в системе мобильной связи UMTS, скоростью загрузки до 5,8 Мбит / с.Высокоскоростной пакетный доступ по восходящей линии (HSUPA) – это способ передачистандарта мобильной радиосвязи UMTS, который обеспечивает более высокие скоростипередачи данных по восходящей линии связи и уменьшает время прохождения в обаконца (часто называемое ping).

* # 7465625 # – Просмотр статуса блокировки телефона.

* 7465625 * 638 * Код # – Включает сетевой замок.

# 7465625 * 638 * Код # – Отключает блокировку сети.

* 7465625 * 782 * Код # – Включает блокировку подмножества.

# 7465625 * 782 * Код # – Отключает блокировку подмножества.

* 7465625 * 77 * Код # – Включает блокировку SP.

# 7465625 * 77 * Код # – Отключает блокировку SP.

* 7465625 * 27 * Код # – Включает блокировку CP.

# 7465625 * 27 * Код # – Отключает блокировку CP.

* 7465625 * 746 * Код # – Включает блокировку SIM-карты.

# 7465625 * 746 * Код # – Отключает блокировку SIM-карты.

* 7465625 * 228 # – Блокировка активации включена.

# 7465625 * 228 # – Блокировка активации выключена.

* 7465625 * 28638 # – Автоматическая сетевая блокировка ВКЛ.

# 7465625 * 28638 # – Автоматическая блокировка сети ВЫКЛ.

* 7465625 * 28782 # – Автоподстановка для включения ВКЛ.

# 7465625 * 28782 # – Автоподстановка блокировки ВЫКЛ.

* 7465625 * 2877 # – Автоматическая блокировка SP ВКЛ.

# 7465625 * 2877 # – Автоматическая блокировка SP ВЫКЛ.

* 7465625 * 2827 # – Автоматическая блокировка CP ВКЛ.

# 7465625 * 2827 # – Автоматическая блокировка CP ВЫКЛ.

* 7465625 * 28746 # = Автоматическая блокировка SIM ВКЛ.

# 7465625 * 28746 # = Автоматическая блокировка SIM-карты ВЫКЛ

* # * # 273283 * 255 * 663282 * # * # * – Этот код открывает экран копированияфайлов, где вы можете создавать резервные копии медиафайлов, например, изображения,звук, видео и звуковые заметки.

* # * # 197328640 # * # * – Этот код можно использовать для входа в сервисныйрежим. Вы можете запускать различные тесты и изменять настройки в сервисном режиме.

[parametrized testing]: параметризованное тестирование

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

Чтобы помочь понять проблему, которую пытается решить параметризованное тестирование, давайте возьмем простой тест для add():

ch2/tasks_proj/tests/func/test_add_variety.py

    """Проверка функции API tasks.add()."""

    import pytest
    import tasks
    from tasks import Task

    def test_add_1():
        """tasks.get () использует id, возвращаемый из add() works."""
        task = Task('breathe', 'BRIAN', True)
        task_id = tasks.add(task)
        t_from_db = tasks.get(task_id)
        # все, кроме идентификатора, должно быть одинаковым
        assert equivalent(t_from_db, task)

    def equivalent(t1, t2):
        """Проверяет эквивалентность двух задач."""
        # Сравнить все, кроме поля id
        return ((t1.summary == t2.summary) and
                (t1.owner == t2.owner) and
                (t1.done == t2.done))

    @pytest.fixture(autouse=True)
    def initialized_tasks_db(tmpdir):
        """Подключает к БД перед тестированием, отключает после."""
        tasks.start_tasks_db(str(tmpdir), 'tiny')
        yield
        tasks.stop_tasks_db()

При создании объекта tasks его полю id присваивается значение None. После добавления и извлечения из базы данных будет задано поле id. Поэтому мы не можем просто использовать ==, чтобы проверить, правильно ли была добавлена и получена наша задача.

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v test_add_variety.py::test_add_1
============================= test session starts =============================

collected 1 item

test_add_variety.py::test_add_1 PASSED

========================== 1 passed in 0.69 seconds ===========================

Тест кажется допустимым. Тем не менее, это просто проверка одной примерной задачи. Что делать, если мы хотим проверить множество вариантов задачи? Нет проблем. Мы можем использовать @pytest.mark.parametrize(argnames, argvalues) для передачи множества данных через один и тот же тест, например:

ch2/tasks_proj/tests/func/test_add_variety.py

    @pytest.mark.parametrize('task',
                             [Task('sleep', done=True),
                              Task('wake', 'brian'),
                              Task('breathe', 'BRIAN', True),
                              Task('exercise', 'BrIaN', False)])
    def test_add_2(task):
        """Демонстрирует параметризацию с одним параметром."""
        task_id = tasks.add(task)
        t_from_db = tasks.get(task_id)
        assert equivalent(t_from_db, task)

Первый аргумент parametrize() — это строка с разделенным запятыми списком имен — ‘task’, в нашем случае. Второй аргумент — это список значений, который в нашем случае представляет собой список объектов Task. pytest будет запускать этот тест один раз для каждой задачи и сообщать о каждом отдельном тесте:

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v test_add_variety.py::test_add_2
============================= test session starts =============================

collected 4 items

test_add_variety.py::test_add_2[task0] PASSED
test_add_variety.py::test_add_2[task1] PASSED
test_add_variety.py::test_add_2[task2] PASSED
test_add_variety.py::test_add_2[task3] PASSED

========================== 4 passed in 0.69 seconds ===========================

Использование parametrize() работает как нам надо. Однако давайте передадим задачи как кортежи, чтобы поглядеть, как будут работать несколько параметров теста:

ch2/tasks_proj/tests/func/test_add_variety.py

    @pytest.mark.parametrize('summary, owner, done',
                             [('sleep', None, False),
                              ('wake', 'brian', False),
                              ('breathe', 'BRIAN', True),
                              ('eat eggs', 'BrIaN', False),
                              ])
    def test_add_3(summary, owner, done):
        """Демонстрирует параметризацию с несколькими параметрами."""
        task = Task(summary, owner, done)
        task_id = tasks.add(task)
        t_from_db = tasks.get(task_id)
        assert equivalent(t_from_db, task)

При использовании типов, которые легко преобразовать в строки с помощью pytest, идентификатор теста использует значения параметров в отчете, чтобы сделать его доступным для чтения:

(venv35) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v test_add_variety.py::test_add_3
============================= test session starts =============================
platform win32 -- Python 3.5.2, pytest-3.5.1, py-1.5.3, pluggy-0.6.0 -- 
cachedir: ...pytest_cache
rootdir: ...bopytest-codecodech2tasks_projtests, inifile: pytest.ini
collected 4 items

test_add_variety.py::test_add_3[sleep-None-False] PASSED                 [ 25%]
test_add_variety.py::test_add_3[wake-brian-False] PASSED                 [ 50%]
test_add_variety.py::test_add_3[breathe-BRIAN-True] PASSED               [ 75%]
test_add_variety.py::test_add_3[eat eggs-BrIaN-False] PASSED             [100%]

========================== 4 passed in 0.37 seconds ===========================

Если хотите, вы можете использовать весь тестовый идентификатор, называемый узлом в терминологии pytest, для повторного запуска теста:

(venv35) c:BOOKbopytest-codecodech2tasks_projtestsfunc>pytest -v test_add_variety.py::test_add_3[sleep-None-False]
============================= test session starts =============================

test_add_variety.py::test_add_3[sleep-None-False] PASSED                 [100%]

========================== 1 passed in 0.22 seconds ===========================

Обязательно используйте кавычки, если в идентификаторе есть пробелы:

(venv35) c:BOOKbopytest-codecodech2tasks_projtestsfunc>pytest -v "test_add_variety.py::test_add_3[eat eggs-BrIaN-False]" 
============================= test session starts =============================

collected 1 item

test_add_variety.py::test_add_3[eat eggs-BrIaN-False] PASSED             [100%]

========================== 1 passed in 0.56 seconds ===========================

Теперь вернемся к списку версий задач, но переместим список задач в переменную вне функции:

ch2/tasks_proj/tests/func/test_add_variety.py

    tasks_to_try = (Task('sleep', done=True),
                    Task('wake', 'brian'),
                    Task('wake', 'brian'),
                    Task('breathe', 'BRIAN', True),
                    Task('exercise', 'BrIaN', False))

    @pytest.mark.parametrize('task', tasks_to_try)
    def test_add_4(task):
        """Немного разные."""
        task_id = tasks.add(task)
        t_from_db = tasks.get(task_id)
        assert equivalent(t_from_db, task)

Это удобно и код выглядит красиво. Но читаемость вывода трудно интерпретировать:

(venv35) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v test_add_variety.py::test_add_4
============================= test session starts =============================

collected 5 items

test_add_variety.py::test_add_4[task0] PASSED                            [ 20%]
test_add_variety.py::test_add_4[task1] PASSED                            [ 40%]
test_add_variety.py::test_add_4[task2] PASSED                            [ 60%]
test_add_variety.py::test_add_4[task3] PASSED                            [ 80%]
test_add_variety.py::test_add_4[task4] PASSED                            [100%]

========================== 5 passed in 0.34 seconds ===========================

Удобочитаемость версии с несколькими параметрами хороша, как и список объектов задачи. Чтобы пойти на компромисс, мы можем использовать необязательный параметр ids для parametrize(), чтобы сделать наши собственные идентификаторы для каждого набора данных задачи.

ch2/tasks_proj/tests/func/test_add_variety.py

    task_ids = ['Task({},{},{})'.format(t.summary, t.owner, t.done)
                for t in tasks_to_try]

    @pytest.mark.parametrize('task', tasks_to_try, ids=task_ids)
    def test_add_5(task):
        """Demonstrate ids."""
        task_id = tasks.add(task)
        t_from_db = tasks.get(task_id)
        assert equivalent(t_from_db, task)

Давайте запустим это и посмотрим, как это выглядит:

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v test_add_variety.py::test_add_5
============================= test session starts =============================

collected 5 items

test_add_variety.py::test_add_5[Task(sleep,None,True)] PASSED
test_add_variety.py::test_add_5[Task(wake,brian,False)0] PASSED
test_add_variety.py::test_add_5[Task(wake,brian,False)1] PASSED
test_add_variety.py::test_add_5[Task(breathe,BRIAN,True)] PASSED
test_add_variety.py::test_add_5[Task(exercise,BrIaN,False)] PASSED

========================== 5 passed in 0.45 seconds ===========================

И эти идентификаторы можно использовать для выполнения тестов:

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v "test_add_variety.py::test_add_5[Task(exercise,BrIaN,False)]"
============================= test session starts =============================

collected 1 item

test_add_variety.py::test_add_5[Task(exercise,BrIaN,False)] PASSED

========================== 1 passed in 0.21 seconds ===========================

Нам определенно нужны кавычки для этих идентификаторов; в противном случае круглые и квадратные скобки будут путать shell. Вы также можете применить parametrize() к классам. При этом одни и те же наборы данных будут отправлены всем методам теста в классе:

ch2/tasks_proj/tests/func/test_add_variety.py

    @pytest.mark.parametrize('task', tasks_to_try, ids=task_ids)
    class TestAdd():
        """Демонстрация параметризации тестовых классов."""

        def test_equivalent(self, task):
            """Похожий тест, только внутри класса."""
            task_id = tasks.add(task)
            t_from_db = tasks.get(task_id)
            assert equivalent(t_from_db, task)

        def test_valid_id(self, task):
            """Мы можем использовать одни и те же данные или несколько тестов."""
            task_id = tasks.add(task)
            t_from_db = tasks.get(task_id)
            assert t_from_db.id == task_id

Вот он в действии:

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v test_add_variety.py::TestAdd
============================= test session starts =============================

collected 10 items

test_add_variety.py::TestAdd::test_equivalent[Task(sleep,None,True)] PASSED
test_add_variety.py::TestAdd::test_equivalent[Task(wake,brian,False)0] PASSED
test_add_variety.py::TestAdd::test_equivalent[Task(wake,brian,False)1] PASSED
test_add_variety.py::TestAdd::test_equivalent[Task(breathe,BRIAN,True)] PASSED
test_add_variety.py::TestAdd::test_equivalent[Task(exercise,BrIaN,False)] PASSED
test_add_variety.py::TestAdd::test_valid_id[Task(sleep,None,True)] PASSED
test_add_variety.py::TestAdd::test_valid_id[Task(wake,brian,False)0] PASSED
test_add_variety.py::TestAdd::test_valid_id[Task(wake,brian,False)1] PASSED
test_add_variety.py::TestAdd::test_valid_id[Task(breathe,BRIAN,True)] PASSED
test_add_variety.py::TestAdd::test_valid_id[Task(exercise,BrIaN,False)] PASSED

========================== 10 passed in 1.16 seconds ==========================

Вы также можете идентифицировать параметры, включив идентификатор рядом со значением параметра при передаче списка в декоратор @pytest.mark.parametrize(). Вы делаете это с помощью синтаксиса pytest.param(<value>, id=”something”) :

В действии:

(venv35) ...bopytest-codecodech2tasks_projtestsfunc
$ pytest -v test_add_variety.py::test_add_6
======================================== test session starts =========================================

collected 3 items

test_add_variety.py::test_add_6[just summary] PASSED                                            [ 33%]
test_add_variety.py::test_add_6[summaryowner] PASSED                                           [ 66%]
test_add_variety.py::test_add_6[summaryownerdone] PASSED                                      [100%]

================================ 3 passed, 6 warnings in 0.35 seconds ================================

Это полезно, когда id не может быть получен из значения параметра.

Gsm-коды для huawei honor 6a.

Переадресация вызова (вам необходимо заказать услугу от оператора):

Измените PIN1 – ** 04 *, затем введите PIN-код старый и дважды новый PIN-код.

Измените PIN2 – ** 042 *, затем введите старый PIN2 и дважды новый PIN2.

Разблокируйте SIM-карту (PIN) – ** 05 *, затем дважды введите PUK и новый PIN-код.

Разблокируйте SIM-карту (PIN2) – ** 052 *, затем дважды введите PUK2 и новый PIN2.

## 002 # – Отменить все переадресации.

## 004 # – Отменить все условные переадресации.

** 004 * номер телефона # – Активировать все условные переадресации.

Безусловная переадресация вызова (Переадресация всех вызовов).

### 21 – Выключить и деактивировать.

# 21 # – Деактивировать.

** 21 * номер телефона # – Включить и активировать.

* 21 # – Активировать.

* # 21 # – Проверить состояние.

Отклонение в случае отсутствия ответа.

### 61 – Выключить и деактивировать.

# 61 # – Отключить.

** 61 * номер телефона # – Включить и активировать.

* 61 # – Активировать

* # 61 # – Проверьте условие.

Установите время вызова, пока опция переадресации вызовов «нет ответа».

При установке пересылки на «нет ответа» вы можете установить время в секундах,которое система позволяет вам подключить. Если за это время вы не подняли телефон,входящий вызов будет перенаправлен.

Пример: – ** 61 * ** 709576617601234 # 30 – установить время ожидания 30 секунд

Установите тайм-аут – ** 61 * Номер телефона ** N #, N = 5..30 (в секундах)

Удалите предыдущую установку – # # 61 #

Отклонение в случае ”

# ## 62 – Выключить и деактивировать

# 62 # – Отключить

** 62 * номер телефона # – Включить и активировать

* 62 # – Активировать

* # 62 # – Проверить состояние

Переадресация в случае «занята»

### 67 – Выключить и деактивировать

# 67 # – Деактивировать

** 67 * номер телефона # – Включить и активировать

* 67 # – Активировать

* # 67 # – Проверить условие

Запрет вызовов (вам нужно заказать услугу у оператора)

Изменить пароль для все запреты (по умолчанию – 0000)

** 03 * 330 * старый пароль * новый пароль * новый пароль #

Запрет всех исходящих вызовов

** 33 * пароль # – Активировать

# 33 * пароль # – Деактивировать

* # 33 # – Проверить условие

Запрет всех вызовов

** 330 * пароль # – Активировать

# 330 * пароль # – Деактивировать

* # 330 # – Проверить условие

Запрет всех исходящих международных вызовов

** 331 * пароль # – Активировать

# 331 * пароль # – Деактивировать

* # 331 # – Проверить условие

Запрет всех исходящих вызовов

** 333 * пароль # – Активировать

# 333 * пароль # – Деактивировать

* # 333 # – Проверить условие

Запрет всех входящих вызовов

** 353 * пароль # – Активировать

# 353 * пароль # – Деактивировать

* # 353 # – Проверить условие

Запрет всех входящих вызовов при роуминге

** 351 * пароль # – Активировать

# 351 * пароль # – Деактивировать

* # 351 # – Проверить состояние

Ожидание вызова (вам необходимо заказать услугу у оператора)

* 43 # – Активировать

# 43 # – Деактивировать

* # 43 # – Проверить состояние

Передать номер телефона (Anti ANI)

# 30 # номер телефона – Блок

* 30 # номер телефона – Разрешить

* # 30 # – Проверить состояние

Показать номер телефона вызывающего абонента (ANI)

# 77 # – Блок

* 77 # – Разрешить

* # 77 # – Проверить состояние

Smart menu

GP – * 111 #

Rob – * 140 #

Banglalink – * 789 #

Marking test functions

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

Маркеры обретут для вас смысл после того, как вы увидите их в действии. Предположим, мы хотим запустить подмножество наших тестов в качестве быстрого “smoke test”, чтобы получить представление о том, есть ли какой-то серьезный разрыв в системе. Smoke tests по соглашению не являются всеобъемлющими, тщательными наборами тестов, но выбранным подмножеством, которое можно быстро запустить и дать разработчик достойное представление о здоровье всех частей системы.

Чтобы добавить набор тестов smoke в проект Tasks, нужно добавить @mark.pytest.smoke для некоторых тестов. Давайте добавим его к нескольким тестам test_api_exceptions.py (обратите внимание, что маркеры smoke и get не встроены в pytest; я просто их придумал):

ch2/tasks_proj/tests/func/test_api_exceptions.py

    @pytest.mark.smoke
    def test_list_raises():
        """list() должно возникнуть исключение с неправильным типом param."""
        with pytest.raises(TypeError):
            tasks.list_tasks(owner=123)

    @pytest.mark.get
    @pytest.mark.smoke
    def test_get_raises():
        """get() должно возникнуть исключение с неправильным типом param."""
        with pytest.raises(TypeError):
            tasks.get(task_id='123')

Теперь давайте выполним только те тесты, которые помечены -m marker_name:

(venv33) ...bopytest-codecodech2tasks_projtests>cd func

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v -m "smoke" test_api_exceptions.py
============================= test session starts =============================

collected 7 items

test_api_exceptions.py::test_list_raises PASSED
test_api_exceptions.py::test_get_raises PASSED

============================= 5 tests deselected ==============================
=================== 2 passed, 5 deselected in 0.18 seconds ====================

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>
(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v -m "get" test_api_exceptions.py
============================= test session starts =============================

collected 7 items

test_api_exceptions.py::test_get_raises PASSED

============================= 6 tests deselected ==============================
=================== 1 passed, 6 deselected in 0.13 seconds ====================

Помните, что -v сокращенно от –verbose и позволяет нам видеть имена тестов, которые выполняются. Использование-m ‘smoke’ запускает оба теста, помеченные @pytest.mark.smoke.

Использование -m ‘get’ запустит один тест, помеченный @pytest.mark.get. Довольно простой.

Все становится чудесатей и чудесатей! Выражение после -m может использовать and, or и not комбинировать несколько маркеров:

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v -m "smoke and get" test_api_exceptions.py
============================= test session starts =============================

collected 7 items

test_api_exceptions.py::test_get_raises PASSED

============================= 6 tests deselected ==============================
=================== 1 passed, 6 deselected in 0.13 seconds ====================

Это мы провели тест только с маркерами smoke и get. Мы можем использовать и not:

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v -m "smoke and not get" test_api_exceptions.py
============================= test session starts =============================

collected 7 items

test_api_exceptions.py::test_list_raises PASSED

============================= 6 tests deselected ==============================
=================== 1 passed, 6 deselected in 0.13 seconds ====================

Добавление -m ‘smoke and not get’ выбрало тест, который был отмечен с помощью @pytest.mark.smoke, но не @pytest.mark.get.

Использование операторов assert

Когда вы пишете тестовые функции, обычный оператор Python-а assert является вашим основным инструментом для сообщения о сбое теста. Простота этого в pytest блестящая. Это то, что заставляет многих разработчиков использовать pytest поверх других фреймворков.

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

С помощью pytest вы можете использовать assert <выражение> с любым выражением. Если выражение будет вычисляться как False, когда оно будет преобразовано в bool, тест завершится с ошибкой.

pytest включает функцию, называемую assert rewriting, которая перехватывает assert calls и заменяет их тем, что может рассказать вам больше о том, почему ваши утверждения не удались. Давайте посмотрим, насколько полезно это переписывание, если посмотреть на несколько ошибок утверждения:

ch2/tasks_proj/tests/unit/test_task_fail.py

    """Используем the Task type для отображения сбоев тестов."""
    from tasks import Task

    def test_task_equality():
        """Разные задачи не должны быть равными."""
        t1 = Task('sit there', 'brian')
        t2 = Task('do something', 'okken')
        assert t1 == t2

    def test_dict_equality():
        """Различные задачи, сравниваемые как dicts, не должны быть равны."""
        t1_dict = Task('make sandwich', 'okken')._asdict()
        t2_dict = Task('make sandwich', 'okkem')._asdict()
        assert t1_dict == t2_dict

Все эти тесты терпят неудачу, но интересна информация в трассировке:

(venv33) ...bopytest-codecodech2tasks_projtestsunit>pytest test_task_fail.py                                     
============================= test session starts =============================                                            

collected 2 items                                                                                                          

test_task_fail.py FF                                                                                                       

================================== FAILURES ===================================                                            
_____________________________ test_task_equality ______________________________                                            

    def test_task_equality():                                                                                              
        """Different tasks should not be equal."""                                                                         
        t1 = Task('sit there', 'brian')                                                                                    
        t2 = Task('do something', 'okken')                                                                                 
>       assert t1 == t2                                                                                                    
E       AssertionError: assert Task(summary=...alse, id=None) == Task(summary='...alse, id=None)                           
E         At index 0 diff: 'sit there' != 'do something'                                                                   
E         Use -v to get the full diff                                                                                      

test_task_fail.py:9: AssertionError                                                                                        
_____________________________ test_dict_equality ______________________________                                            

    def test_dict_equality():                                                                                              
        """Different tasks compared as dicts should not be equal."""                                                       
        t1_dict = Task('make sandwich', 'okken')._asdict()                                                                 
        t2_dict = Task('make sandwich', 'okkem')._asdict()                                                                 
>       assert t1_dict == t2_dict                                                                                          
E       AssertionError: assert OrderedDict([...('id', None)]) == OrderedDict([(...('id', None)])                           
E         Omitting 3 identical items, use -vv to show                                                                      
E         Differing items:                                                                                                 
E         {'owner': 'okken'} != {'owner': 'okkem'}                                                                         
E         Use -v to get the full diff                                                                                      

test_task_fail.py:16: AssertionError                                                                                       
========================== 2 failed in 0.30 seconds ===========================

Вот это да! Это очень много информации. Для каждого неудачного теста точная строка ошибки отображается с помощью > указателя на отказ. Строки E показывают дополнительную информацию о сбое assert, чтобы помочь вам понять, что пошло не так.

Я намеренно поставил два несовпадения в test_task_equality(), но только первое было показано в предыдущем коде. Давайте попробуем еще раз с флагом -v, как предложено в сообщении об ошибке :

(venv33) ...bopytest-codecodech2tasks_projtestsunit>pytest -v test_task_fail.py
============================= test session starts =============================

collected 2 items

test_task_fail.py::test_task_equality FAILED
test_task_fail.py::test_dict_equality FAILED

================================== FAILURES ===================================
_____________________________ test_task_equality ______________________________

    def test_task_equality():
        """Different tasks should not be equal."""
        t1 = Task('sit there', 'brian')
        t2 = Task('do something', 'okken')
>       assert t1 == t2
E       AssertionError: assert Task(summary=...alse, id=None) == Task(summary='...alse, id=None)
E         At index 0 diff: 'sit there' != 'do something'
E         Full diff:
E         - Task(summary='sit there', owner='brian', done=False, id=None)
E         ?                ^^^  ^^^          ^^^^
E           Task(summary='do something', owner='okken', done=False, id=None)
E         ?                   ^^^  ^^^          ^^^^

test_task_fail.py:9: AssertionError
_____________________________ test_dict_equality ______________________________

    def test_dict_equality():
        """Different tasks compared as dicts should not be equal."""
        t1_dict = Task('make sandwich', 'okken')._asdict()
        t2_dict = Task('make sandwich', 'okkem')._asdict()
>       assert t1_dict == t2_dict
E       AssertionError: assert OrderedDict([...('id', None)]) == OrderedDict([(...('id', None)])
E         Omitting 3 identical items, use -vv to show
E         Differing items:
E         {'owner': 'okken'} != {'owner': 'okkem'}
E         Full diff:
E         {'summary': 'make sandwich',
E         -  'owner': 'okken',
E         ?                ^...
E
E         ...Full output truncated (5 lines hidden), use '-vv' to show

test_task_fail.py:16: AssertionError
========================== 2 failed in 0.28 seconds ===========================

Ну, я думаю, что это чертовски круто! pytest не только смог найти оба различия, но и показал нам, где именно эти различия. В этом примере используется только equality assert; на веб-сайте pytest.org можно найти еще много разновидностей оператора assert с удивительной информацией об отладке трассировки.

Пропуск тестов (skipping tests)

Хотя маркеры, обсуждаемые в методах проверки маркировки, на стр. 31 были именами по вашему выбору, pytest включает в себя несколько полезных встроенных маркеров: skip, skipif, и xfail. В этом разделе я расскажу про skip и skipif, а в следующем -xfail.

Маркеры skip и skipif позволяют пропускать тесты, которые не нужно выполнять. Для примера, допустим, мы не знали, как должна работать tasks.unique_id(). Каждый вызов её должен возвращает другой номер? Или это просто номер, который еще не существует в базе данных?

Во-первых, давайте напишем тест (заметим, что в этом файле тоже есть фикстура initialized_tasks_db; просто она здесь не показана):

ch2/tasks_proj/tests/func/test_unique_id_1.py

    """Test tasks.unique_id()."""

    import pytest
    import tasks

    def test_unique_id():
        """Вызов unique_id () дважды должен возвращать разные числа."""
        id_1 = tasks.unique_id()
        id_2 = tasks.unique_id()
        assert id_1 != id_2

Затем дайте ему выполниться:

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest test_unique_id_1.py            
============================= test session starts =============================                     

collected 1 item                                                                                    

test_unique_id_1.py F                                                                               

================================== FAILURES ===================================                     
_______________________________ test_unique_id ________________________________                     

    def test_unique_id():                                                                           
        """Calling unique_id() twice should return different numbers."""                            
        id_1 = tasks.unique_id()                                                                    
        id_2 = tasks.unique_id()                                                                    
>       assert id_1 != id_2                                                                         
E       assert 1 != 1                                                                               

test_unique_id_1.py:11: AssertionError                                                              
========================== 1 failed in 0.30 seconds ===========================                     

Хм. Может быть, мы ошиблись. Посмотрев на API немного больше, мы видим, что docstring говорит “””Return an integer that does not exist in the db.”””, что означает Возвращает целое число, которое не существует в DB. Мы могли бы просто изменить тест. Но вместо этого давайте просто отметим первый, который будет пропущен:

ch2/tasks_proj/tests/func/test_unique_id_2.py

    @pytest.mark.skip(reason='misunderstood the API')
    def test_unique_id_1():
        """Вызов unique_id () дважды должен возвращать разные числа."""
        id_1 = tasks.unique_id()
        id_2 = tasks.unique_id()
        assert id_1 != id_2

    def test_unique_id_2():
        """unique_id() должен вернуть неиспользуемый id."""
        ids = []
        ids.append(tasks.add(Task('one')))
        ids.append(tasks.add(Task('two')))
        ids.append(tasks.add(Task('three')))
        # захват уникального id
        uid = tasks.unique_id()
        # убеждаемся, что его нет в списке существующих идентификаторов
        assert uid not in ids

Отметить тест, который нужно пропустить, так же просто, как добавить @pytest.марк.skip() чуть выше тестовой функции.

Повторим :

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v test_unique_id_2.py
============================= test session starts =============================

collected 2 items

test_unique_id_2.py::test_unique_id_1 SKIPPED
test_unique_id_2.py::test_unique_id_2 PASSED

===================== 1 passed, 1 skipped in 0.19 seconds =====================

Теперь предположим, что по какой-то причине мы решили, что первый тест также должен быть действительным, и мы намерены сделать эту работу в версии 0.2.0 пакета. Мы можем оставить тест на месте и использовать вместо этого skipif:

ch2/tasks_proj/tests/func/test_unique_id_3.py

    @pytest.mark.skipif(tasks.__version__ < '0.2.0',
                        reason='not supported until version 0.2.0')
    def test_unique_id_1():
        """Вызов unique_id () дважды должен возвращать разные числа."""
        id_1 = tasks.unique_id()
        id_2 = tasks.unique_id()
        assert id_1 != id_2

Выражение, которое мы передаем в skipif(), может быть любым допустимым выражением Python. В этом конкретном, нашем случае, мы проверяем версию пакета. Мы включили причины как в skip, так и в skipif. Это не требуется в skip, но это требуется в skipif.

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest test_unique_id_3.py
============================= test session starts =============================

collected 2 items

test_unique_id_3.py s.

===================== 1 passed, 1 skipped in 0.20 seconds =====================

s. показывает, что один тест был пропущен(skipped), и один тест прошел(passed). Мы можем посмотреть, какой из них где-куда опцией -v:

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -v test_unique_id_3.py
============================= test session starts =============================

collected 2 items

test_unique_id_3.py::test_unique_id_1 SKIPPED
test_unique_id_3.py::test_unique_id_2 PASSED

===================== 1 passed, 1 skipped in 0.19 seconds =====================

Но мы все еще не знаем почему. Мы можем взглянуть на эти причины с -rs:

(venv33) ...bopytest-codecodech2tasks_projtestsfunc>pytest -rs test_unique_id_3.py
============================= test session starts =============================

collected 2 items

test_unique_id_3.py s.
=========================== short test summary info ===========================
SKIP [1] functest_unique_id_3.py:8: not supported until version 0.2.0

===================== 1 passed, 1 skipped in 0.22 seconds =====================

Параметр -r chars содержит такой текст справки:

$ pytest --help
...
    -r chars
    show extra test summary info as specified by chars
    (показать дополнительную сводную информацию по тесту, обозначенному символами)
    (f)ailed, (E)error, (s)skipped, (x)failed, (X)passed,
    (p)passed, (P)passed with output, (a)all except pP.
...

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

Создание файлов формата junit¶

Чтобы создать результирующие файлы в формате, понятном Jenkins
или другому серверу непрерывной интеграции, используйте вызов:

Команда создает xml-файл по указанному пути.

Чтобы задать имя корневого xml-элемента для набора тестов, можно настроить параметр
junit_suite_name в конфигурационном файле:

Спецификация JUnit XML, по-видимому, указывает, что атрибут “time” должен сообщать
об общем времени выполнения теста, включая выполнение setup- и teardown- методов
(1, 2).

Это поведение pytest по умолчанию. Чтобы вместо этого сообщать только о длительности вызовов,
настройте параметр junit_duration_report следующим образом:

Тестирование пакета

Чтобы узнать, как писать тестовые функции для пакета Python, мы будем использовать пример проекта Tasks, как описано в проекте Tasks на странице xii. Задачи представляет собой пакет Python, который включает в себя инструмент командной строки с тем же именем, задачи.

Приложение 4 «Packaging and Distributing Python Projects» на стр. 175 включает объяснение того, как распределять ваши проекты локально внутри небольшой команды или глобально через PyPI, поэтому я не буду подробно разбираться в том, как это сделать; однако давайте быстро рассмотрим, что находится в проекте «Tasks» и как разные файлы вписываются в историю тестирования этого проекта.

Ниже приведена файловая структура проекта Tasks:

tasks_proj/
├── CHANGELOG.rst
├── LICENSE
├── MANIFEST.in
├── README.rst
├── setup.py
├── src
│ └── tasks
│ ├── __init__.py
│ ├── api.py
│ ├── cli.py
│ ├── config.py
│ ├── tasksdb_pymongo.py
│ └── tasksdb_tinydb.py
└── tests
├── conftest.py
├── pytest.ini
├── func
│ ├── __init__.py
│ ├── test_add.py
│ └── ...
└── unit
├── __init__.py
├── test_task.py
└── ...

Я включил полный список проекта (за исключением полного списка тестовых файлов), чтобы указать, как тесты вписываются в остальную часть проекта, и указать на несколько файлов, которые имеют ключевое значение для тестирования, а именно conftest.py, pytest.ini, различные __init__.py файлы и setup.py.

Все тесты хранятся в tests и отдельно от исходных файлов пакета в src. Это не требование pytest, но это лучшая практика.

Все файлы верхнего уровня, CHANGELOG.rst, LICENSE, README.rst, MANIFEST.in, и setup.py, более подробно рассматриваются в Приложении 4, Упаковка и распространение проектов Python, на стр. 175. Хотя setup.py важен для построения дистрибутива из пакета, а также для возможности установить пакет локально, чтобы пакет был доступен для импорта.

Функциональные и модульные тесты разделены на собственные каталоги. Это произвольное решение и не обязательно. Однако организация тестовых файлов в несколько каталогов позволяет легко запускать подмножество тестов. Мне нравится разделять функциональные и модульные тесты, потому что функциональные тесты должны ломаться, только если мы намеренно изменяя функциональность системы, в то время как модульные тесты могут сломаться во время рефакторинга или изменения реализации.

Проект содержит два типа файлов __init__.py: найденные в каталоге src/ и те, которые находятся в tests/. Файл src/tasks/__init__.py сообщает Python, что каталог является пакетом. Он также выступает в качестве основного интерфейса для пакета, когда кто-то использует import tasks.

Он содержит код для импорта определенных функций из api.py, так что cli.py и наши тестовые файлы могут обращаться к функциям пакета, например tasks.add(), вместо того, чтобы выполнять task.api.add ().

Файл pytest.ini не является обязательным. Он содержит общую конфигурацию pytest для всего проекта. В вашем проекте должно быть не более одного из них. Он может содержать директивы, которые изменяют поведение pytest, например, настрйки списка параметров, которые всегда будут использоваться. Вы узнаете все о pytest.ini в главе 6 «Конфигурация» на стр. 113.

Файл conftest.py также является необязательным. Он считается pytest как “local plugin” и может содержать hook functions и fixtures. Hook functions являются способом вставки кода в часть процесса выполнения pytest для изменения работы pytest.

Fixtures — это setup и teardown функции, которые выполняются до и после тестовых функций и могут использоваться для представления ресурсов и данных, используемых тестами. (Fixtures обсуждаются в главе 3, pytest Fixtures, на стр. 49 и главе 4, Builtin Fixtures, на стр.

71, а hook functions бсуждаются в главе 5 «Плагины» на стр. 95.) Hook functions и fixtures, которые используются в тестах в нескольких подкаталогах, должны содержаться в tests/conftest.py. Вы можете иметь несколько файлов conftest.py; например, можно иметь по одному в тестах и по одному для каждой поддиректории tests.

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

Вот test_task.py:

ch2/tasks_proj/tests/unit/test_task.py

    """Test the Task data type."""

    # -*- coding: utf-8 -*-
    from tasks import Task

    def test_asdict():
        """_asdict() должен возвращать словарь."""
        t_task = Task('do something', 'okken', True, 21)
        t_dict = t_task._asdict()
        expected = {'summary': 'do something',
                    'owner': 'okken',
                    'done': True,
                    'id': 21}
        assert t_dict == expected

    def test_replace():
        """replace () должен изменить переданные данные в полях."""
        t_before = Task('finish book', 'brian', False)
        t_after = t_before._replace(id=10, done=True)
        t_expected = Task('finish book', 'brian', True, 10)
        assert t_after == t_expected

    def test_defaults():
        """Использование вызова без параметров должно применить значения по умолчанию."""
        t1 = Task()
        t2 = Task(None, None, False, None)
        assert t1 == t2

    def test_member_access():
        """Проверка .field  функциональность namedtuple."""
        t = Task('buy milk', 'brian')
        assert t.summary == 'buy milk'
        assert t.owner == 'brian'
        assert (t.done, t.id) == (False, None)

В файле test_task.py указан этот оператор импорта:

    from tasks import Task

Лучший способ позволить тестам импортировать tasks или что-то импортировать из tasks — установить tasks локально с помощью pip. Это возможно, потому что есть файл setup.py для прямого вызова pip.

Установите tasks, запустив pip install . или pip install -e . from the tasks_proj directory. Или другой вариант запустить pip install -e tasks_proj из каталога на один уровень выше:

$ cd /path/to/code
$ pip install ./tasks_proj/
$ pip install --no-cache-dir ./tasks_proj/
Processing ./tasks_proj
Collecting click (from tasks==0.1.0)
  Downloading click-6.7-py2.py3-none-any.whl (71kB)
  ...
Collecting tinydb (from tasks==0.1.0)
  Downloading tinydb-3.4.0.tar.gz
Collecting six (from tasks==0.1.0)
  Downloading six-1.10.0-py2.py3-none-any.whl
Installing collected packages: click, tinydb, six, tasks
  Running setup.py install for tinydb ... done
  Running setup.py install for tasks ... done
Successfully installed click-6.7 six-1.10.0 tasks-0.1.0 tinydb-3.4.0

Если вы хотите только выполнять тесты для tasks, эта команда подойдет. Если вы хотите иметь возможность изменять исходный код во время установки tasks, вам необходимо использовать установку с опцией -e (для editable “редактируемый”):

$ pip install -e ./tasks_proj/
Obtaining file:///path/to/code/tasks_proj
Requirement already satisfied: click in
  /path/to/venv/lib/python3.6/site-packages (from tasks==0.1.0)
Requirement already satisfied: tinydb in
  /path/to/venv/lib/python3.6/site-packages (from tasks==0.1.0)
Requirement already satisfied: six in
  /path/to/venv/lib/python3.6/site-packages (from tasks==0.1.0)
Installing collected packages: tasks
  Found existing installation: tasks 0.1.0
    Uninstalling tasks-0.1.0:
      Successfully uninstalled tasks-0.1.0
  Running setup.py develop for tasks
Successfully installed tasks

Теперь попробуем запустить тесты:

$ cd /path/to/code/ch2/tasks_proj/tests/unit
$ pytest test_task.py
===================== test session starts ======================
collected 4 items
test_task.py ....
=================== 4 passed in 0.01 seconds ===================

Импорт сработал! Остальные тесты теперь могут безопасно использовать задачи импорта. Теперь напишем несколько тестов.