Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Создание тестового окружения перед тестированием

codeception
rest
Теги: #<Tag:0x00007f7b6d6ca990> #<Tag:0x00007f7b6d6ca828>

(Andrey Kurilov) #1

Приветствую! Вопрос по REST модулю. Меня уже долгое время не покидает вопрос. Как сделать возможность создания тестового окружения для прогона остальных тестов средствами самого codeception. Ведь у меня есть api, я с ним общаюсь, но, часто в проекте я начал использовать одни и те же функции в разных тестах.

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

И вот мысль. Первым тестом создать все необходимые для дальнейших тестов сущности, записать информацию о них в какую-нибудь глобальную переменную и использовать её в дальнейших тестах. Возможно это? Посоветуйте, поделитесь опытом.


(Michael Bodnarchuk) #2

Мне кажется, что лучше использовать заранее заготовленные данные, которые будут оставаться константными для всех тестов. Мы можем из использовать, с ними связываться, но не менять их. Например, пользователь №1 будет использоваться для логина.

Но если мы захотим проверить создание пользователя - мы создадим пользователя №2.

ЗЫ: У меня как раз точно сейчас такая же ситуация, нужно проверить изменения пароля для пользователя, а он у меня, увы, пока один )


(Andrey Kurilov) #3

Жаль. Ведь у тестировщика обычно 2 сервера для тестирования как минимум - trunk и beta. Они имеют разные адреса(решается через --env), beta вобще может работать с production базой. Это заставит создать Page с кучей переменных для разного окружения, при этом необходимо всегда содержать в неизменном виде аккаунты, в которых работают тесты. Сегодня я напишу такой тест, завтра уволюсь, потом придет другой тестировщик, что-то поменяет в аккаунте, тесты упадут из-за того, что поменялся\удалился какой-нибудь id. Он будет сидеть, ругаться, переписывать :slight_smile:
А можно было бы просто запустить тест, который умеет работать с API моего сервиса, в шаге _before создает все, что нужно для последующих тестов, заполняет конфиг\глобальную переменную, прогоняет тесты, в которых так же можно переопределять\добавлять глобальные переменные. Тесты прошли, запустился _clean и удалил всё, что было создано. Красота :slight_smile:
Очень хочется такого. С Codeception я работаю уже более 3-х лет и очень доволен. Спасибо вам за разработку. Но вот не хватает именно того, что я описал для полного удовлетворения. Может быть в планах есть хоть малейший намек на это? :relaxed:


(Michael Bodnarchuk) #4

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


(Andrey Kurilov) #5

Окей. Буду искать пути выхода :slight_smile: Спасибо


(Evgeny Luvsandugar) #6

Мне кажется есть несколько вариантов решения проблемы:

  1. Если тесты данные не меняют, то можно создать их один раз, залить в образ vagrant/docker/… и потом в процессе CI создавать окружение уже с данными.
  2. Не знаком с Codeception, но во всех тестовых фреймворках с которыми я работыл были tearup/teardown функции, для разных уровней (все тесты/сьют/тест), можно там создавать если это поддерживается.
  3. Использовать библиотеки для создания тестовых данных/фикстур. Типа как для руби factory_girl/Fabrication/machinist, для питона factory_boy и создавать данные непосредственно в тесте. Этот вариант удобен тем, что тесты становятся независимы, можно запускать параллельно, не боясь что они начнут драться за данные.

Ну и можно совместить все варианты вместе)


(Andrey Kurilov) #7

Хочется настроить 1 файл, который в дальнейшем будет изменяться и дополняться, а в остальных тестах обращаться к глобальным переменным, созданным этим тестом. Если что-то поменялось в api - поменял в одном файле и все, а если в каждом тесте будет создаваться окружение, необходимое для прохождения этого теста, то редактировать 100500 тестов как-то неправильно :slight_smile:

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


(Evgeny Luvsandugar) #8

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

А фикстуры работают не через API, они запишут в базу напрямую (но тут опять же я не силен в PHP, работал так только с Rails и Django, там все работает like magic). Описание моделей сущностей для фикстур как раз будет в отдельных файлах.


(Andrey Kurilov) #9

Не совсем так. Апи, обычно, меняется не кардинально в рамках одной версии. Оно может дополняться ответами или новыми методами. Есть класс, который работает с апи, с классом работают тесты. Класс меняем - тесты нет(пока не будет api v2).


(Andrey Kurilov) #10

Заюзал для временного хранилища memcache. Сейчас переменные, заготовленные одним тестом, записываются в memcache и забираются оттуда другим тестом :smile: