Спасибо за ссылку. На первый взгляд pexpect более «низкоуровневый» (что, несомненно, также может пригодиться), fabric же скрывает множество нюансов позволяя просто писать строчки команд, определяя на какой машине они будут исполняться (локально или где-то на сервере через SSH). Т.е. Если нужно просто выполнить скрипт из набора команд — fabric позволяет не писать рутинных функций.
Ну это по потребностям — каждый подгонит под себя. Можно вообще через командную строку все аргументы принимать с дефолтом под наиболее частое применение. Я сейчас делаю так: если что-то пришлось выполнить более трёх раз — добавляю возможность делать это через скрипт, а штучные команды пишу в консоли. Ключик --all пока мне не приходилось использовать ни разу — вот его и нет…
Статьи разные нужны, статьи разные важны. Счётчик избранного показывает, что статья вполне себе востребована. Каждому нужно с чего-то начать и этой статьи вполне достаточно, чтоб разобраться в основных принципах.
Хотят встроенными средствами покрыть все варианты тестирования? Похвально, ещё бы webtest туда включили, он побыстрее селениума и достаточен, если не нужно JavaScript тестить…
В теории да — там должен быть запущен selenium-standalone и необходимый браузер (не знаю как на счёт зоопарка). Настройки по этой части можно подсмотреть здесь: j.mp/wQTSKu в разделе Remote
Сам я не эксперементировал с таким вариантом потому подробнее не подскажу.
Это вместо геопланировщиков, понятно. А они как-то зашиврованы или это обычные NFC метки? Т.е. смогу я использовать ваши метки с телефоном, скажем… ладно, с телефоном другой компании? Естественно при наличии на том телефоне необходимого софта…
Прошу прощения за самопиар, но он по теме. Тут небольшие выводы из моего опыта использования этого самого бесплатного микро инстанса — бежал я оттуда как от огня. Тот же наш clodo.ru и то пощедрее будет ресурсами, и обходился менее 500р./мес, сейчас вообще ушёл на selectel.ru — так и того меньше выходит. В общем ссылка на мой опыт, кому интересно blog.qnub.ru/2011/03/amazon.html
Мне кажется это совсем уж спорный вопрос, особенно, если учитывать, что мы тут даже виртуальное окружение проверяем на работоспособность — мало ли чего там в реализации не так. Вдруг оно будет пахать в памяти, а на планируемом мускуле не полетит? Миграции не промигрируются?
Понятно что быстрее, но я лично от греха подальше пускаю тесты в той же СУБД что будет на боевой системе…
Да, но я не стал углубляться в тонкости правильного конфигурирования всех параметров (тем более что у меня — я единственный коммитер, а писал я мануал со своей ситуации), портянка и так длинная. Целью было минимально настроить и поднять все компоненты чтобы автоматом собиралось и тестилось. Думаю про нюансы настройки можно накропать ещё не один такой рулон писанины…
а у меня обратная ситуация. дженкинс не создал файлы конфигурации там где должен (если верить документации) после установки, а разбираться стало лень. :) рад что оказался полезен!
У меня непреодолимое ощущение что я где-то это читал, причём с такой же картинкой…
Сам я не эксперементировал с таким вариантом потому подробнее не подскажу.
Кроме того django_nose нужно добавить в INSTALLED_APPS файла settings.py вашего django проекта.
Конечно, можно и в TEST_RUNNER если не хочется в INSTALLED_APPS не принципиально. Добавлю как примечание. Спасибо.
Понятно что быстрее, но я лично от греха подальше пускаю тесты в той же СУБД что будет на боевой системе…