Ускоренное тестирование модуля: Поймать неудачный тест

Question

Я запускаю тест, в котором открывается USB-устройство, пакет отправляется и принимается, и он снова закрывается. Это выглядит следующим образом:

void TestCase1(void) 
{ 
int recv; 
BOOST_REQUIRE(initDevice()); 
BOOST_REQUIRE(openDevice()); 
BOOST_REQUIRE_EQUAL(receiveData(), 5); 
BOOST_REQUIRE(closeDevice()); 
BOOST_REQUIRE(uninitDevice()); 
} 

Теперь, когда есть ошибка в receiveData() вызова и Проверка на «5» не удается, closeDevice() и uninitDevice() не называются больше, и я не могу использовать устройство в следующем тесте , Есть ли способ справиться с этим? Может быть, поймать исключение и закрыть и uninit устройство в этой области захвата тоже? Или это полный неправильный подход? Я довольно новичок в модульном тестировании. Поэтому любая помощь приветствуется. Благодаря!

Answer 1

Я хотел бы использовать один из ключевых понятий в современном C++, RAII, чтобы помочь сохранить initDevice/uninitDevice и openDevice/closeDevice привязанную вместе:

class USBDeviceHandler 
{ 
public: 
    USBDeviceHandler() 
    : initDeviceHandle { ::initDevice()), &::uninitDevice }, 
     openDeviceHandle { ::openDevice()), &::closeDevice } 
    { 
    } 

    using init_handle = std::unique_ptr<void, decltype(&::uninitDevice)>; 
    using open_handle = std::unique_ptr<void, decltype(&::closeDevice)>; 

    init_handle initDeviceHandle; 
    open_handle openDeviceHandle; 
}; 

void TestCase1(void) 
{ 
int recv; 
USBDeviceHandler device; //init/open is called upon construction 
BOOST_REQUIRE_EQUAL(receiveData(), 5); 
}//close/uninit is called upon destruction 

Это базируется пример, приведенный в Rule of Zero.

Answer 2

Вы должны использовать BOOST_CHECK и BOOST_CHECK_EQUAL, если хотите сообщить о состоянии, которое не удовлетворено, но при этом продолжайте проверку. В этом случае, возможно, первые два элемента должны быть «REQUIRE» d, а последние три должны быть «CHECK» ed.

Answer 3

Возможно, вам будет лучше делать то, что должно произойти сначала в настройке прибора и убирать его с помощью функции срыва. Очевидно, использование OO с RAII и помещение receiveData в качестве метода класса позволило бы избежать этого.
В качестве альтернативы, BOOST_CHECK проверит состояние и продолжит проверку, если это не удастся, что позволит избежать проблемы, возникшей у вас, когда BOOST_REQUIRE останавливает остальную часть выполняемого теста.