Есть ли графический интерфейс для тестирования носа - PullRequest
5 голосов
/ 12 марта 2009

Последние несколько месяцев я использовал тесты на нос для запуска своих тестов на Python.

Он определенно делает свою работу, но он не очень хорош для того, чтобы наглядно увидеть, какие тесты работают или не работают.

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

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

Есть рекомендации?

Ответы [ 4 ]

4 голосов
/ 30 марта 2010

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

2 голосов
/ 18 ноября 2009

Я использовал Trac + Bitten для непрерывной интеграции, это была довольно сложная установка и требовала значительного количества времени для RTFM, настройки и последующего обслуживания, но я мог получать хорошие визуальные отчеты с ошибочными тестами, сообщениями об ошибках и графиками для провал тестов, проблемы с Pylint и покрытие кода с течением времени.

Bitten - плагин непрерывной интеграции для Trac. Имеет архитектуру мастер-раб. Укушенный мастер интегрирован и работает вместе с Trac. Укушенный подчиненный может быть запущен в любой системе, которая взаимодействует с мастером. Он будет регулярно опрашивать мастера по задачам сборки. Если есть незавершенная задача (кто-то недавно что-то зафиксировал), мастер отправит «рецепт сборки», подобный муравьиному build.xml, подчиненному, подчиненный будет следовать рецепту и отправит результаты. Рецепт может содержать такие инструкции, как «получить код из этого хранилища», «выполнить этот сценарий оболочки», «запустить тестирование носа в этом каталоге». Отчеты о сборке и статистика отображаются в Trac.

0 голосов
/ 20 января 2014

Мне нравится открывать второй терминал рядом с моим редактором, в котором я просто запускаю цикл, который повторно запускает тесты носа (или любую тестовую команду, например обычные старые тесты юнитов) каждый раз, когда изменяется любой файл. Затем вы можете сохранить фокус в окне редактора, при этом каждый раз, когда вы нажимаете «сохранить» в вашем редакторе, вы увидите, как обновляются результаты теста.

Я не уверен, что OP подразумевает под "детализацией", но лично все, что мне нужно из результатов теста, - это обратная связь по сбою, которая, конечно же, отображается при каждом сбое теста.

Это особенно эффективно, когда ваш код и тесты хорошо написаны, так что подавляющему большинству ваших тестов требуется всего лишь миллисекунды для запуска. Я мог бы запускать эти быстрые модульные тесты в цикле, как описано выше, во время редактирования или отладки, а затем запускать любые более длительные тесты вручную в конце, непосредственно перед тем, как выполнить коммит.

Вы можете повторно запускать тесты вручную, используя Bash 'watch' (но он просто запускает их каждые X секунд. Это нормально, но не настолько быстро, чтобы я был счастлив.)

В качестве альтернативы я написал быстрый пакет python 'rerun', который опрашивает изменения файловой системы, а затем повторно запускает команду, которую вы ему даете. Опрос на изменения не идеален, но его было легко написать, он полностью кроссплатформенный, довольно быстрый, если вы скажете ему опрашивать каждые 0,25 секунды, не вызывает у меня заметного лага или нагрузки на систему даже в больших проектах ( например, дерево исходного кода Python), и работает даже в сложных случаях (см. ниже.) https://pypi.python.org/pypi/rerun/

Третья альтернатива - использовать более универсальную программу «ожидания изменений файловой системы», такую ​​как «watchdog», но она казалась тяжелой для моих нужд, и подобные решения, которые прослушивают события файловой системы, иногда не работают, когда я ожидаемый (например, если Vim сохраняет файл, сохраняя tmp где-то в другом месте, а затем перемещая его на место, события, которые происходят иногда, не те, которые вы ожидаете.) Следовательно, 'rerun'.

0 голосов
/ 11 июля 2012

Я знаю, что этот вопрос задавался 3 года назад, но в настоящее время я разрабатываю графический интерфейс, чтобы немного облегчить работу с тестами носа над проектом, в котором я участвую.

В нашем проекте используется PyQt , благодаря которому было действительно легко начать работу с этим графическим интерфейсом, поскольку он предоставляет все необходимое для создания интерфейсов. Я давно не работал с Python, но с ним довольно легко разобраться, поэтому, если вы знаете, что делаете, это будет прекрасно, если у вас будет время.

Вы можете преобразовать файлы .UI, созданные в PyQt Designer, в сценарии Python с помощью:

pyuic4 -x interface.ui -o interface.py

И вы можете получить несколько хороших руководств, чтобы почувствовать PyQt здесь . Надеюсь, что это поможет кому-то:)

...