Приветствую! Вопрос по REST модулю. Меня уже долгое время не покидает вопрос. Как сделать возможность создания тестового окружения для прогона остальных тестов средствами самого codeception. Ведь у меня есть api, я с ним общаюсь, но, часто в проекте я начал использовать одни и те же функции в разных тестах.
Например: Есть некая основная сущность, с которой работают несколько других сущностей. В каждой из этих сущностей я обращаюсь к основной сущности, НО так как тесты разные, то приходится ID основной сущности хранить всегда и не удалять. Но в ходе тестов у меня создается точно такая же основная сущность, ведь функциорал её создания тоже нужно проверить.
И вот мысль. Первым тестом создать все необходимые для дальнейших тестов сущности, записать информацию о них в какую-нибудь глобальную переменную и использовать её в дальнейших тестах. Возможно это? Посоветуйте, поделитесь опытом.
Мне кажется, что лучше использовать заранее заготовленные данные, которые будут оставаться константными для всех тестов. Мы можем из использовать, с ними связываться, но не менять их. Например, пользователь №1 будет использоваться для логина.
Но если мы захотим проверить создание пользователя - мы создадим пользователя №2.
ЗЫ: У меня как раз точно сейчас такая же ситуация, нужно проверить изменения пароля для пользователя, а он у меня, увы, пока один )
Жаль. Ведь у тестировщика обычно 2 сервера для тестирования как минимум - trunk и beta. Они имеют разные адреса(решается через --env), beta вобще может работать с production базой. Это заставит создать Page с кучей переменных для разного окружения, при этом необходимо всегда содержать в неизменном виде аккаунты, в которых работают тесты. Сегодня я напишу такой тест, завтра уволюсь, потом придет другой тестировщик, что-то поменяет в аккаунте, тесты упадут из-за того, что поменялся\удалился какой-нибудь id. Он будет сидеть, ругаться, переписывать
А можно было бы просто запустить тест, который умеет работать с API моего сервиса, в шаге _before создает все, что нужно для последующих тестов, заполняет конфиг\глобальную переменную, прогоняет тесты, в которых так же можно переопределять\добавлять глобальные переменные. Тесты прошли, запустился _clean и удалил всё, что было создано. Красота
Очень хочется такого. С Codeception я работаю уже более 3-х лет и очень доволен. Спасибо вам за разработку. Но вот не хватает именно того, что я описал для полного удовлетворения. Может быть в планах есть хоть малейший намек на это?
к сожалению у вас настолько специфичная задача, что я не уверен, что я пойму что вам нужно. Попробуйте реализовать в своем хэлпере описанные вами шаги. Вы можете в начале теста выполнить запросы к апи используя, допустим, тот же Guzzle напрямую, подготовить среду, а в конце в методе _after отправить запросы и удалить только что созданные данные
Мне кажется есть несколько вариантов решения проблемы:
Если тесты данные не меняют, то можно создать их один раз, залить в образ vagrant/docker/… и потом в процессе CI создавать окружение уже с данными.
Не знаком с Codeception, но во всех тестовых фреймворках с которыми я работыл были tearup/teardown функции, для разных уровней (все тесты/сьют/тест), можно там создавать если это поддерживается.
Использовать библиотеки для создания тестовых данных/фикстур. Типа как для руби factory_girl/Fabrication/machinist, для питона factory_boy и создавать данные непосредственно в тесте. Этот вариант удобен тем, что тесты становятся независимы, можно запускать параллельно, не боясь что они начнут драться за данные.
Хочется настроить 1 файл, который в дальнейшем будет изменяться и дополняться, а в остальных тестах обращаться к глобальным переменным, созданным этим тестом. Если что-то поменялось в api - поменял в одном файле и все, а если в каждом тесте будет создаваться окружение, необходимое для прохождения этого теста, то редактировать 100500 тестов как-то неправильно
Если что-то сломалось, то и тестовое окружение не создастся, соответственно я быстрее пойму что что-то сломалось, без ожидания прохождения всех тестов.
Так если меняется API то в любом случае надо менять тесты, они же апи и тестируют А если используется, что-то типа cucumber, то тесты трогать не придется, менятся код в одном месте, и сразу все тесты используют новый API.
А фикстуры работают не через API, они запишут в базу напрямую (но тут опять же я не силен в PHP, работал так только с Rails и Django, там все работает like magic). Описание моделей сущностей для фикстур как раз будет в отдельных файлах.
Не совсем так. Апи, обычно, меняется не кардинально в рамках одной версии. Оно может дополняться ответами или новыми методами. Есть класс, который работает с апи, с классом работают тесты. Класс меняем - тесты нет(пока не будет api v2).
testomat.io управление авто тестами
А если используется, что-то типа cucumber, то тесты трогать не придется, менятся код в одном месте, и сразу все тесты используют новый API.