Ошибка boost :: unit_test, потому что дочерний процесс завершается с ненулевым значением - PullRequest
Новая
       13

Ошибка boost :: unit_test, потому что дочерний процесс завершается с ненулевым значением

4 голосов
/ 16 марта 2011

У меня есть следующий код: 

bool f()
{
  command = "mkdir -p /\/\/";
  result = aSystemCall(command);
  if (result == ...
}

BOOST_AUTO_TEST_CASE(BadDir)
{
  BOOST_CHECK_EQUAL(false, f());
}

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

mkdir: cannot create directory '/\/\/': Permission denied
unknown location(0): fatal error in "BadDir": child has exited; pid: 25356; uid: 19753;   exit value: 1
test.cpp(100): last checkpoint
Leaving test case "BadDir"; testing time: 10ms
Leaving test suite "Test"
Leaving test suite "Master Test Suite"

Если я запускаю BadDir контрольный пример в GDB, aSystemCall возвращает, результат может быть проверен, и тест проходит.

Есть ли способ заставить boost :: unit_test отфильтровывать возможные ошибки, подобные этой, чтобы выполнение могло продолжаться? Я пробовал BOOST_AUTO_TEST_CASE_EXPECTED_FAILURE(blah, 1), но это просто для того, чтобы сказать boost :: unit_test, что вы ожидаете сбой. Он сообщает об обнаруженном сбое (ожидаемый сбой) в тесте. Вместо этого я хотел бы пройти тестовую ситуацию.

Ответы [ 5 ]

4 голосов
/ 03 декабря 2013

Прежде всего, я получаю это странное поведение только в Linux.

Я обнаружил, что Boost.Test меняет способ обработки дочерних кодов выхода с выбранной вами моделью развертывания.Если вы используете статическое связывание библиотек наддува или заголовок «все в одном» boost/test/included/unit_test.hpp, вставляющий определение: 

#define BOOST_TEST_IGNORE_NON_ZERO_CHILD_CODE

до того, как любая директива включения решит проблему.

Если вы используете динамическое связывание, этого недостаточно.Вы должны либо вызвать итоговый тест с параметром командной строки "- catch_system_errors = no" , либо определить следующую переменную окружения. 

export BOOST_TEST_CATCH_SYSTEM_ERRORS="no"

Я использую boost 1.52 и 1.57, GCC 4.7.2, на Debian Wheezy.

Вот ссылка на модели развертывания Boost.Test

см. Также этот вопрос: how-к отмене смертельного исхода-обнаружения ошибок-в-буст-тест

1 голос
/ 10 августа 2011

Добавление --catch_system_errors = no во время выполнения также работает.

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

1 голос
/ 16 марта 2011

Это решено в более поздней версии Boost.Test

0 голосов
/ 05 декабря 2014

Немного расшифровав ответ Чипа Кристиана : (пере) компиляция boost.test с флагом BOOST_TEST_IGNORE_NON_ZERO_CHILD_CODE (проверено на повышение 1.53).В командной строке bjam добавьте: 

cxxflags="-DBOOST_TEST_IGNORE_NON_ZERO_CHILD_CODE"

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

touch boost/test/impl/execution_monitor.ipp
0 голосов
/ 04 октября 2014

Если вы запускаете свой тест из терминала, вы должны установить для переменной среды Boost значение «no» catch_system_errors . В случае Ubuntu OS, перед выполнением теста необходимо набрать следующую команду в терминале: 

export BOOST_TEST_CATCH_SYSTEM_ERRORS="no"
...