Это вопрос к тестируемости системы

api для удобства автотестов никто делать не будет, спрашивали

занятость программистов очень высокая

А техдолг?

А рефакторинг и устойчивость системы?

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

тут тоже имелась ввиду подготовка данных с помощью api? или как-то по-другому?

Да как угодно. Хошь скрпитами, хочешь руками в апи, хочешь запрос генери в постмане. Зависит от структуры тестируемого объекта.

есть мнение, чтобы подготавливать нужные данные запросом в БД, но у нас bitrix и куча таблиц и похоже, что это нереально)

Тогда страдайте

Или возьмите и придумайте как вы ваш зоопарк будете тестировать . Когда-то разве были другие альтернативы?

Страдаем ) Думали, что может мы не одни такие и кто-то справился с такими проблемами, написали сюда за помощью)

Ну так надо как-то более конкретно. Вы сейчас просите сферической помощи в вакууме )

Много таблиц

Лапки

и не знаем какие таблицы

Кажется это вопрос коммуникации , не?

и не знаем какие таблицы

так почему нельзя узнать то?

да как бы не вопрос, спрашивали, но просто на начальном этапе написания автотестов все дружно пришли к тому, что подготвавливать данные через запрос в бд неверно и надо все протыкивать )

а сейчас тестов много, времени занимают много, все бьётся на микросервисы и возникает много попаболи )

Я понял, как вариант, нам нужно продавливать другой подход и конкретно через БД ) Займёмся этим) Спасибо за мнения)

Товарищи, добрый день Не совсем силен в терминах. Тут в схеме в разделе "Testing activities" встречается термин PDV(ADS) execution on build. Подскажите, пожалуйста, что тут подразумевается? Сформулировать четкий и ясный ответ для себя из гугла так и не смог.

@dmitrypozdeev Тут есть, собственно, несколько вариантов: 1) Протыкивать. Долго, мучительно и не стабильно. Для некоторых кейсов это довольно сложно заменить (напр. когда часть состояния системы хранится с рантайме, то прокидывать этот стейт из вне будет довольно проблематично) 2) Дергать соотв. ручки: как уже говорилось раньше, это может быть отдельная ручка в API, может быть скрипт, дергающих уже существующее API в нужной последовательности. Ответ "Для автотестов никто пилить API не будет" - в корне не верен. Если команде нужно повышать скорость и стабильность автотестов - это задача всей команды, учитесь вести переговоры. 3) Готовить данные на уровне БД. Тут копать в сторону Database Seeding и читать, что и как. Самая большая проблема - обеспечить в сидинге консистетность данных, а так же определить какой объем данных и в каком состоянии вам нужно сидировать. 4) Переиспользовать имеющиеся данные. Смысл простой: найти сущность в нужном вам состоянии в уже имеющихся данных и заиспользовать. Это могут быть данные из прошлых тестов, прошлых прогонов или вообще дамп базы с продакшена. Если нет подходящих сущностей - тогда уже готовить. Вариант, опять же, весьма ситуативный, посколько в таком случае работе в тестах идет с dirty данными, что не исключает false positive \ false negative результатов. С другой стороны надо понимать, что тестировать только не стерильных данных - тоже так себе. Ну, и для некоторых кейсов, где подготовка данных ограничена - он становится оптимальным.

Как всё это делать, в каком соотношении и виде - слишком сильно зависит от вашего приложения и конкретного теста.

@azshoo Спасибо, 4ый вариант нам тоже предлагали, но мы от него отказались, так как если тесты выполняются параллельно, то два теста могут взять данные с одинаковым ID и понятно, что какой-то тест точно упадет.

@azshoo Спасибо, 4ый вариант нам тоже предлагали, но мы от него отказались, так как если тесты выполняются параллельно, то два теста могут взять данные с одинаковым ID и понятно, что какой-то тест точно упадет.

Да, поэтому нужен отдельный провайдер выдающий эти данные.

Довольно простая инженерная задача. :)

Видать активное обсуждение сейчас из вакансий перейдет сюда)

Довольно простая инженерная задача. :)

Подскажи в каком направлени посмотреть/подумать, если мы выбираем эти данные рандомно.

Подскажи в каком направлени посмотреть/подумать, если мы выбираем эти данные рандомно.

Ну, смотрите. У вас есть условный DataProvider, отвечающий за поиск и выдачу нужных данных из базы. Вам от него нужно 3 вещи: 1) Что бы он понимал, что вы от него хотите (т.е. находил валидные данные) 2) Что бы он возвращал их в нужном формате на output. 3) Что бы он гарантировал уникальность этих данных в рамках сессии. С первыми двумя всё более-менее понятно. Для третьего сохраняете в условный redis\монгу\любое другое хранилище данных выдаваемые данные и исключаете их из результатов последующих поисков. Для исключение конкурентности запросов можно ещё на input поставить очередь.

Если есть желание создать космолет - можно к этому добавить ещё и изменение состояния -> т.е. после того, как на entity уже отработал один тест -> она становится из Busy в Used, и может быть использована в других тестах.

потому что есть определенные рамки нейминга для тестов

если вы используете phpunit то он требует чтобы название теста начиналось со слова test

Если есть желание создать космолет - можно к этому добавить ещё и изменение состояния -> т.е. после того, как на entity уже отработал один тест -> она становится из Busy в Used, и может быть использована в других тестах.

Спасибо тебе за такие развернутые ответы. Признаться честно, у нас была такая идея, но мы не стали её продавливать, видимо время пришло )

Ну, как я уже говорил - решение довольно спорное. Всё сильно зависит от контекста, где-то это всё оправдано, где-то нет.

файлами, которые пропишите в бутстрап, а бутстрап в конфиге прокиньте

откройте документацию уже

как вам удобно, но думаю если пользуетесь codeception, лучше использовать его фичи

это для голового своего фреймворка, но codeception сам умеет это прокидывать

это по запросу в гугле первой строчкой

бутстрап это файлик который подгружает необходимые для работы файлы в php, вы в нем можете указать необходимые файлы для загрузки, но ваш фреймворк позволяет в своем файле настроек это указать

посредник убирается при дебаге

Мне кажется вам нужна документация пхп юнит и кодсепшен, а не чатик.

Читать. Документацию.

http://codeception.com/docs/01-Introduction

можно я за вас буду получать вашу зарплату если буду решать ваши проблемы

Ты просто немного путаешь. В этом чатике ты не то, что бы клиент, а остальные - не то, что бы сотрудники техподдержки.

Читать за тебя документацию никто не будет, как и головой думать.

а если найду

вы знаете что такое bootstrap.php ?

это знания php с третей версии

а правда в гугле нет ничего по этому поводу?

и надо наезжать на людей в чатике за то, что они не помогают?

а правда в гугле нет ничего по этому поводу?

это вопрос понимания ответов гугла а, и мастерства задавания вопросов

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

_bootstrap codeception'а дублирует bootstrap проекта + свои шаблончики догружает, куда прописывать в автолоад это можете монетку кинуть, но этот самый бутстрап подгружается в конфиге codeception.yml который являет собой обертку над phpunit.yml

хоть в любое место засовывайте - будет работать

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

включите авиа режим

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

Что же это за утройства такие?