Святослав Белимов лучше DateTime, формат unix time платформозависим, на 32 битной архитектуре корректо работает только в диапазоне [1970-01-01, 2038-01-19]
Да кстати есть позиции разрабов которые открыты чуть ли не круглый год - помониторьте работные сайты. Для соискателя шансы устроиться туда минимальны, можно сходить только за "поболтать".
Если вы имеете в виду Selenium Webdriver, то он легко интегрируется в Сodeception на уровне приемочных (user acceptance) тестов. codeception.com/docs/03-AcceptanceTests см. Selenium
Запускать юнит, функциональные и приемочные тесты можно как вместе, так и под отдельности.
>>а так как в доках пишут про менеджера пишущего фитчу ... ну и что он там напишет? "кликаю сюда вижу сообщение success" ? а то что у меня за этой кнопкой 10 итераций он даже и не знает
Да Behat просто нацелен на команды которые активно пишут спеки, где либо манагер с техбекграундом, либо есть отдельные QA команда/спец, которые как правило не знают php. Если все тесты пишут php разработчики, на мой взгляд Codeception уместнее.
Рестартаните сервисы (php, апач), попытайтесь запустить простейший скрипт (echo 'test'; exit;) - мб ваше приложение в новом окружении стучится куда-то и не может получить доступ.
Если не получится, значит надо копать в сторону конфигов:
1. Таймаут апача должен быть не меньше таймаута у cgi php (60 секунд обычно).
2. Отключить access логи.
3. Посмотреть через какой-нибудь ps aux | grep php какие есть процессы, может что-то в фоне блочит выполнение php. Посмотреть скорость записи/чтения с дисков.
Либо форкать расширение либо наследоваться от behaviors/ImageBehave, добавив в метод getImages необязательный аргумент-условие выборки (например $searchCondition). Если $searchCondition задан - добавлять его в качестве дополнительного условия выборки через andWhere.
magary4: дело вкуса. Мне Behat меньше нравится из-за:
- синтаксического языка спецификаций Gherkin вместо привычного php. Для англоговорящих QA спецов не знакомых с php это плюс, для php разработчиков скорее минус.
- менее user friendly доки (у codeception подумали про тестирование api, quickstart под фреймворки и т.п., в behat тоже что-то такое есть, но все мудренее и искать дольше, ИМХО)
Насколько больших? Данные отдаются локально или по сети?
Если речь про файлы размером 100-10000 MB, рассмотрите вариант просто хранить их на диске. Кеш ОС скорее всего будет эффективнее.
Вы на правильном пути.
1. Рекомендую использовать codeception.com как полноценный фреймворк для тестирования.
2. Если времени не вагон, то между функциональным (ваш пункт 2) и приемочным (ваш пункт 3) тестированием я бы отдавал предпочтение последнему. Причина: все то же самое, но с клиентским js и полноценным тестированием пользовательских сценариев.
Ivan Palamarchuk: Можно gearman, можно кролика. Redis в классической сборке не персистентный, я бы не использовал его как брокера сообщений в принципе.
Поднимите бек и фронт у себя локально, ведите код в одном репо. Под фичи отдельные ветки, но для одного человека git flow избыточен ИМХО. С GUI связываться не рекомендую, командная строка - наше все ;)
Разбейте задачу на составляющие:
1.) Вебсервер и бизнес-логика API
2.) Фоновая обработка
Начните с п.1, т.е. реализуйте простейшее API с обычной обработкой. Потом переведите обработку на фон.
Я бы сделал через очереди, т.е. API создает какую-то задачу с параметрами и id в бд, ставит сообщение в очередь и в ответе отдает id задачи, типа "узнавайте готовность задачи по этому id".
Далее брокер отдает сообщение консьюмеру (обработчику), тот обрабатывает задачу и обновляет ее статус.
Если потребуется параллелить нагрузку, просто добавляете дополнительные обработчики.