Я использую PyTest для написания своих юнит-тестов, и мне это очень нравится. В последнее время появилась необходимость в сквозных / приемочных тестах, и, поскольку у меня был плохой опыт работы с платформой приемочных тестов, я решил провести некоторое исследование, если возможно написать сквозные тесты в PyTest.
Я не буду вдаваться в подробности о тестируемой системе, но приложения будут получать 3 сообщения от клиента (в формате JSON), посыпать их магией бизнес-уровня и затем вывести 7 сообщений обратно клиенту. Вот пара вопросов о структуре и дизайне тестов:
Часть setup должна создать 3 сообщения JSON и отправить их в тестируемую систему. Я не уверен, fixtures - это правильный способ справиться с этим, но приспособления для меня - это способ вернуть объект с состоянием. Так что я бы предположил, что мой setup - это то же самое, только в большем объеме. Итак, допустим, у меня есть прибор с именем setup (область действия модуля), который выполняет те многочисленные действия, которые необходимы для работы теста (создание сообщения 3 JSON и его отправка). Мой инстинкт подсказывает мне, что у меня не должно быть более одного setup прибора на тестовый файл / тестовый класс, однако я не уверен, сколько тестов мне нужно иметь. Я могу сделать его более «единичным» и провести 7 тестов. Каждый будет использовать одно сообщение и проверять правильность данных сообщения. Или - поскольку 3 сообщения выводят 7 сообщений, и между настройкой и результатами существует прямая связь, я должен использовать один тест, который проверяет все 7 сообщений в нем. Это сделает мой тестовый метод более сложным, потому что утверждение отдельных значений из возвращенного JSON, вероятно, является плохой идеей - если первое сообщение не будет выполнено, я не смогу узнать, в порядке ли 6 оставшихся сообщений, или нет (это, конечно, проще узнать что пошло не так, когда увидишь всю картину). Поэтому для правильной работы одного теста мне нужно будет написать метод, который сравнивает все 7 сообщений с ожидаемыми результатами, а затем выдает одно утверждение с информацией о том, какое из 7 сообщений не удалось и почему. Таким образом, при проверке 7 сообщений в контексте тестирования это выглядит правильно, но оно более сложное и не следует «проверить одну вещь и быть простым».
setup создает сущность с именем random_test_entity (наряду со многими другими сущностями). Тесту нужна эта информация для утверждения. Таким образом, установочное приспособление может либо вернуть dict со всеми этими значениями, которые мне понадобятся позже в моем тесте, ИЛИ - я могу создать другое приспособление, которое будет возвращать dict со значениями, которые будут использовать и установочное приспособление, и тест. Проблема здесь в том, что мне нужно обмениваться данными и состоянием между моими приборами и тестом. И поскольку у меня нет умного способа сделать это, мой прибор возвращает данные, которые не связаны строго с настройкой, что кажется странным. Прибор, возвращающий список значений, мне кажется странным, но я также делю установочный прибор на несколько приборов, чтобы я мог обмениваться данными.
Я использую Git-репозиторий Ptest в качестве своей библии о том, как писать юнит-тесты. Я узнал много нового о дизайне тестов. Можно ли использовать какой-либо источник, чтобы научиться правильно писать сквозные тесты?
Спасибо всем!