ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | output debugging info if a test aborts with a strange exit status | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Ivan Zakharyaschev <imz> | ||||
| Component: | libshell | Assignee: | Alexey Gladkov <legion> | ||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | legion | ||||
| Version: | unstable | ||||||
| Hardware: | all | ||||||
| OS: | Linux | ||||||
| URL: | https://gitorious.org/altlinux/libshell_imz/commits/unittest/debug-strange-status | ||||||
| Attachments: |
|
||||||
|
Description
Ivan Zakharyaschev
2012-03-12 08:38:29 MSK
New localtion of my code: https://gitorious.org/altlinux/libshell_imz/commits/unittest/debug-strange-status Этот бранч содержит не только финальные изменения, но и ваши искания; там содержится изменение спека, который менять можно лишь для релиза; в ваших содержатся примеры использования каких-то команд (этому не место в коде); у вас в коде присутствуют пробелы в конце строки. Бранч unittest/debug-strange-status не то, что можно смерджить. Кроме того, мне не понятна первопричина для этих изменений. Unittest на то и unit, чтобы было понятно что и где сломалось. Если какой-либо проект имеет невнятную диагностику, то стоит исправлять тест, а не фреймворк. Ещё меня смущает идея повторного выполнения теста. Некоторые тесты могут быть довольно длительные и их повтор может быть долгим. Делать это автоматически (без контроля пользователя) мне кажется неправильным. Реакции нет больше года. Закрываю, до появления заинтересованных. Прошу прощения за отсутствие своевременной реакции! Вот что подумалось к этому обсуждению: (В ответ на комментарий №2) > Кроме того, мне не понятна первопричина для этих изменений. Unittest на то и > unit, чтобы было понятно что и где сломалось. Если какой-либо проект имеет > невнятную диагностику, то стоит исправлять тест, а не фреймворк. Дело было в том, что было ничего непонятно: что с тестом (т.к. из-за особенностей окружения код возврата не соответствовал тому, что ожидал вот этот запсукатель тестов). > Ещё меня смущает идея повторного выполнения теста. Некоторые тесты могут быть > довольно длительные и их повтор может быть долгим. Делать это автоматически > (без контроля пользователя) мне кажется неправильным. Да, возражение понятно. Тогда можно остановиться на таком простом решении и ничего не городить: дать руками запустить ещё раз именно этот тест с загадочным status и, возможно, всяким включённым tracing. Это же лучше делать через shell-unittest; как самому запустить отдельный тест не очень понятно? По крайней мере, я бы предложил не проглатывать неожиданный status молча, а реагировать на него как на failed: case "$rc" in 0) passed=$(($passed+1)) ;; 1) failed=$(($failed+1)); retval=1; ;; 2) skipped=$(($skipped+1)) ;; + *) + # It's safer to fail in this case (to draw the attention of the maintainer). + failed=$(($failed+1)); retval=1; ;; esac run_or_exit messageTest "$1" "$msg" "$rc" run_or_exit tearDown и дать совет, как запустить конкретный тест самому руками. В этом есть смысл. Посмотрите в master. Я добавил переменную окружения TESTCASES, в которой можно перечислить юниттесты, которые нужно выполнить. Также если выставить переменную окружения TESTTRACE=1 каждый тест будет запускаться с set -x. libshell-0.3.0-alt1 -> sisyphus: * Tue Feb 24 2015 Alexey Gladkov <legion@altlinux> 0.3.0-alt1 - New version (0.3.0). - Fix bootstrap (ALT#29584). - shell-ini-config changes: + Add ini_config_is_set() function. + Take care about lines without values (ALT#30713). - shell-unittest changes: + Add TESTCASES variable to list individual testcases (ALT#27059). + Add TESTTRACE variable to run testcase in debug mode (ALT#27059). |
