Bug 27059

Summary: output debugging info if a test aborts with a strange exit status
Product: Sisyphus Reporter: Ivan Zakharyaschev <imz>
Component: libshellAssignee: 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 Flags
git diff upstream...unittest/debug-strange-status none

Description Ivan Zakharyaschev 2012-03-12 08:38:29 MSK
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.
Comment 1 Ivan Zakharyaschev 2013-01-22 19:19:27 MSK
New localtion of my code: https://gitorious.org/altlinux/libshell_imz/commits/unittest/debug-strange-status
Comment 2 Alexey Gladkov 2013-01-24 00:37:44 MSK
Этот бранч содержит не только финальные изменения, но и ваши искания; там содержится изменение спека, который менять можно лишь для релиза; в ваших содержатся примеры использования каких-то команд (этому не место в коде); у вас в коде присутствуют пробелы в конце строки.

Бранч unittest/debug-strange-status не то, что можно смерджить.

Кроме того, мне не понятна первопричина для этих изменений. Unittest на то и unit, чтобы было понятно что и где сломалось. Если какой-либо проект имеет невнятную диагностику, то стоит исправлять тест, а не фреймворк.

Ещё меня смущает идея повторного выполнения теста. Некоторые тесты могут быть довольно длительные и их повтор может быть долгим. Делать это автоматически (без контроля пользователя) мне кажется неправильным.
Comment 3 Alexey Gladkov 2015-02-10 12:50:49 MSK
Реакции нет больше года. Закрываю, до появления заинтересованных.
Comment 4 Ivan Zakharyaschev 2015-02-10 20:55:57 MSK
Прошу прощения за отсутствие своевременной реакции!

Вот что подумалось к этому обсуждению:

(В ответ на комментарий №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

и дать совет, как запустить конкретный тест самому руками.
Comment 5 Alexey Gladkov 2015-02-14 15:06:43 MSK
В этом есть смысл. Посмотрите в master. Я добавил переменную окружения TESTCASES, в которой можно перечислить юниттесты, которые нужно выполнить. Также если выставить переменную окружения TESTTRACE=1 каждый тест будет запускаться с set -x.
Comment 6 Repository Robot 2015-02-24 15:56:11 MSK
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).