Created attachment 5375 [details] git diff upstream...unittest/debug-strange-status libshell-0.1.6-alt1 The motivation for the enhancement: ----------------------------------- I couldn't figure out why one of my tests for gear--when run in hasher--reported a strange exit status (whereas when done by a simple "rpm -bb", the test passed). It should be more convenient to see the reason for such an unexpected strange exit status of a test. So, to help myself understand the reason, I modified shell-unittest to output some debugging info in this case (simply, the output of "set -x"). With the debugging info now, the build of gear with the problematic test looks like this: make: Entering directory `/usr/src/RPM/BUILD/gear-1.7.2.6' cd tests && ./run [status=128, to be run again with debugging output] (gear_import_check_lost_cwd) + rc=0 ++ gear_import_check_lost_cwd ++ finalize_repo= ++ gear_import_check_lost ++ local v ++ mkdir -p .git/.work + msg= + rc=128 + set +x [status=128] (gear_import_check_lost_cwd) And I'm able to find the point in the script where this happens. (The explanation for the strange exit status in my test for gear was probably a bashism there.) The patch: ---------- My modifications are in branch "unittest/debug-strange-status" in git://gitorious.org/libshell/imz.git ( https://gitorious.org/libshell/imz/commits/unittest/debug-strange-status ); "git diff upstream...unittest/debug-strange-status" looks like displayed here: https://gitorious.org/libshell/imz/commit/8aa223336c7cc8a9b636ad12c57d87161bd84f73/diffs/e30f11e98849f47ff49f4142f9797d1c5305c4d5 . The patch is also attached below.
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).
