2013-04-10 1 views
7

Возможно ли, чтобы прибор был инициализирован только один раз и использовал его в нескольких тестовых случаях в одном наборе тестов? В следующем примере, приспособление построено и разрушено несколько раз:Возможно ли инициализировать прибор только один раз и использовать его в нескольких тестовых случаях?

struct F { 
    F() : i(0) { BOOST_TEST_MESSAGE("setup fixture"); } 
    ~F()   { BOOST_TEST_MESSAGE("teardown fixture"); } 

    int i; 
}; 


BOOST_FIXTURE_TEST_SUITE(s, F) 

BOOST_AUTO_TEST_CASE(test_case1) 
{ 
    BOOST_CHECK(i == 1); 
} 

BOOST_AUTO_TEST_CASE(test_case2) 
{ 
    BOOST_CHECK_EQUAL(i, 0); 
} 

BOOST_AUTO_TEST_SUITE_END() 

Но я хочу, светильник будет построен только один раз, как начинается набор тестов и общим для всех тестовых примеров в ней. Является ли это возможным? Деструктор будет вызван после выхода из набора тестов.
Я использую Boost Test Framework, но не имею проблем с использованием других фреймворков, таких как UnitTest ++.

+0

Целью приспособления является подготовка среды для всех тестовых случаев. Зачем нужно готовить его до первого дела, но не для других? – harper

+1

@harper Предположим, что я открываю сокет, который будет использоваться во всех тестовых случаях. Я не хочу, чтобы открывать и закрывать сокет для каждого тестового примера. Я хочу открыть его только один раз, использовать его в нескольких тестовых случаях, а затем закрыть его после завершения последнего теста. – 2013-04-10 06:17:59

+0

http://boost.2283326.n4.nabble.com/Boost-Test-Initialize-fixture-only-once-td2626388.html –

ответ

19

Каждый тест является производным от Test Suite Крепеж, который построен в начале каждого теста и деградировавших, когда он завершает (в вашем случае как test_case1 & test_case2 получены из F). Прибор конфигурирует и очищает среду для каждого отдельного тестового примера.

Для модульного тестирования это, как правило, предпочтительная стратегия - каждый тестовый случай является автономным и полностью атомарным.

В некоторых сценариях (например, интеграционном тестировании) предпочтительнее приобретать дорогостоящий ресурс один раз и удерживать его над всеми тестовыми примерами. Это можно сделать с помощью GLOBAL FIXTURE, которая создается в начале тестового прогона и разрушается, когда тест завершается.

Если какие-либо тестовые примеры требуют другой настройки/конфигурации глобальных ресурсов, тогда GLOBAL FIXTURE не может использоваться, и вы должны пересмотреть свою стратегию тестирования, чтобы каждый тестовый пример настраивал и очищал собственную среду.

К сожалению, тестовые случаи не имеют прямого доступа к глобальному испытательному оборудованию, и вам необходимо предоставить механизм, который позволит им получить доступ к ресурсу (например, через глобальную переменную или одноточечный).

В приведенном ниже примере MyFixture является одноэлементным, который содержит ресурс. , например.

struct MyFixture 
{ 
    static MyFixture*& instance() { static MyFixture* s_inst = 0; 
    return s_inst; } 

    MyFixture() 
    { 
     instance() = this; 
     x = 10; 
     BOOST_TEST_MESSAGE("setup fixture"); 
    } 

    ~MyFixture() 
    { 
     BOOST_TEST_MESSAGE("teardown fixture"); 
    } 

    int x; 
}; 

BOOST_GLOBAL_FIXTURE(MyFixture) 


BOOST_AUTO_TEST_CASE(TEST_1) 
{ 
    BOOST_CHECK(MyFixture::instance()->x == 10); 
    MyFixture::instance()->x = 12; 
} 
BOOST_AUTO_TEST_CASE(TEST_2) 
{ 
    BOOST_CHECK(MyFixture::instance()->x == 12); 
} 
Смежные вопросы