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).