Autotesting

Question 1

По степени изолированности тестируемых частей кода функциональные тесты принято делить на три типа:

Answer 1

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

Question 2

Хорошие тесты

Answer 2

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

Question 3

пограничные случаи — ситуации, в которых код может вести себя по-особенному:

Answer 3

• Работа с пустой строкой
• Обработка None
• Деление на ноль (в большинстве языков вызывает ошибку)
• Специфические ситуации для конкретных алгоритмов

Question 4

цикломатической сложностью

Answer 4

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

Question 5

нужно ли внутри capitalize() обрабатывать число вместо строки?

Answer 5

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

Ответственность за передачу правильных данных в функцию capitalize() лежит не на самой функции, а на коде, который вызывает эту функцию.

Question 6

Сколько нужно тестов?

Answer 6

Но даже если ошибка обрабатывается внутри функции, не надо пытаться написать тесты, покрывающие каждую ошибку. Это выливается в огромное число тестов, которые требуют поддержки и времени на написание. Нужно уметь вовремя остановиться и двигаться дальше, к покрытию другого кода.

Question 7

Можно ли сказать, что протестированный код точно не содержит ошибок?

Answer 7

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

Question 8

Выберите идеальный способ работы с тестами при возникновении багов в коде

Answer 8

Пишем тест, в котором баг воспроизводится, потом правим код и проводим тест еще раз

Question 9

Что важно для тестов в большинстве ситуаций?

Answer 9

Выполняет ли код свою задачу

Question 10

Как правильно проверить функцию is_none()?

Answer 10

assert is_none(None)

Question 11

Какое утверждение подойдет, если нужно проверить, что 3 — это простое число?

Answer 11

assert is_prime(3)

Question 12

Какое утверждение лучше подходит для ситуации, когда надо проверить длину строки?

Answer 12

assert len(‘str’) == 3

Question 13

Печать при запуске Pytest

Answer 13

Если понадобится распечатать что-то на экран, то Pytest ничего не выведет. По умолчанию он перехватывает и подавляет весь вывод. Отключить это поведение можно с помощью флага -s:

poetry run pytest -s

Question 14

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

Answer 14

def test_reverse():
    assert reverse('Hexlet') == 'telxeH'

Question 15

В какой директории должны лежать тесты Pytest?

Answer 15

tests

Question 16

Как правильно запускать Pytest на выполнение?

Answer 16

poetry run pytest
pytest

Question 17

Какой флаг отключает подавление вывода на экран при вызове pytest?

Answer 17

-s

Question 18

Что такое модульное тестирование?

Answer 18

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

Question 19

Что проверяет первый тест?

Answer 19

Первый тест всегда должен проверять позитивный сценарий — тот, в котором задействована основная функциональность тестируемого компонента

Question 20

несколько проверок в рамках одного теста

Answer 20

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

Question 21

Какие сценарии для отдельного теста?

Answer 21

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

Question 22

Нужно ли пытаться найти все варианты?

Answer 22

Не нужно. Каждая написанная строчка кода в проекте — потенциальное место для изменения в случае правок. Если есть сомнения, нужно ли писать проверку или нет, то лучше не пишите. Так вы найдете тот минимум, который стоит писать. Редкие ситуации требуют покрытия тестами только тогда, когда они критичны для работоспособности.

Question 23

Как вызвать исключение IndexError в PyTest?

Answer 23

Проверить что вызывается конкретное исключение можно с помощью конструкции
~~~
with pytest.raises(IndexError):
stack.pop()
~~~

Question 24

Действия при возникновении ошибки, для которой не было теста

Answer 24

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

Question 25

Сколько утверждений можно использовать в одном тесте?

Question 26

Сколько утверждений можно использовать в одном тесте?

Answer 26

Столько, сколько нужно для проверки

Question 27

Что будет если хотя бы одна из тестовых функций поменяет эту коллекцию?
(фикстуры)

Answer 27

Для решения этой проблемы тестовые фреймворки предоставляют хуки — специальные функции, которые запускаются до или после тестов. В Pytest их называют фикстурами

Question 28

синтаксис фикстуры

Answer 28

Имя параметра совпадает с именем фикстуры

@pytest.fixture
def coll(): # имя фикстуры выбирается произвольно
    return ['One', True, 3, False]

Pytest сам прокидывает результат вызова функции там, где функция указана в аргументе
def test_compact(coll):
    result = compact(coll)
    assert result == # Тут ожидаемое значение

# Не важно, что предыдущий тест сделал с коллекцией
# Здесь коллекция будет новая, так как pytest вызывает coll() заново

Question 29

Описание фикстуры

Answer 29

Декоратор @pytest.fixture добавляет произвольную функцию в процесс выполнения тестов. Фикстура выполняется перед теми тестами, в которых ее запросили через параметры функции. Важно, что имя аргумента совпадает с именем фикстуры.

Question 30

Почему нужно использовать фикстуры при работе со временем?

Answer 30

now = datetime.now()
def test_foo():
    print(now)

def test_bar():
    print(now)

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

Question 31

Пример фикстур для работы со временем

Answer 31

@pytest.fixture
def current_time():
    return datetime.now()

def test_foo(current_time):
    print(current_time)

def test_bar(current_time):
    print(current_time)

Question 32

Как использовать фикстуру в тестовой функции?

Answer 32

Передать через параметр, имя которого совпадает с именем фикстуры

Question 33

Как создать фикстуру?

Answer 33

С помощью декоратора @pytest.fixture

Question 34

Как должны выполняться тесты?

Answer 34

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

Question 35

Где можно размещать утверждения?

Answer 35

Внутри самого теста

Question 36

В каких случаях стоит разбить один тест на два разных?

Answer 36

Когда тест проверяет другой сценарий, который невозможно выразить в исходном сценарии

Question 37

В чем состоит особенность doctest?

Answer 37

Это идея, когда документация выполняет роль тестов

Question 38

Можно ли писать тесты без тестовых фреймворков?

Answer 38

Да, в Python есть встроенная возможность тестировать через документацию

Question 39

Почему важно измерять покрытие кода тестами?

Answer 39

Оно позволяет найти места, которые не покрыты тестами

Question 40

Как проверка покрытия кода влияет на скорость выполнения тестов?

Answer 40

Скорость падает

Question 41

Как изменится покрытие кода, если во время прогона тесты упали с ошибкой?

Answer 41

Покрытие уменьшится

Question 42

Зачем писать тесты до кода?

Answer 42

Чтобы ускорить работу, ведь написанный тест помогает при последующих изменениях
Чтобы посмотреть на код с точки зрения удобства пользователей

Question 43

Что нужно знать, чтобы написать тесты на функцию до реализации этой функции?

Answer 43

Какая сигнатура будет у этой функции

Question 44

Какой код сложнее тестировать?

Answer 44

Недетерминированный код
Код с побочными эффектами

Question 45

Как называется механизм, реализующий непрерывную интеграцию на GitHub?

Answer 45

GitHub Actions

Question 46

Стоит ли использовать непрерывную интеграцию?

Answer 46

Да, ведь локального запуска тестов или линтера недостаточно

Question 47

Какие операции выполняются при непрерывной интеграции?

Answer 47

Запуск линтера, тестов, утилит безопасности и проверки зависимостей