2016-06-02 7 views
3

Я пытаюсь написать unittest случаях для некоторых файлов cpp в моем проекте.Как выполнить тестирование функции std :: bind с помощью gtest?

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

Здесь частные методы вызывают в общедоступном методе как метод обратного вызова. Как проверить частные методы здесь. Я буду делать издевательский указатель Callback, и я не уверен, как вызвать частный метод.

Просьба дать мне несколько предложений о том, как вызвать частные методы в этом сценарии без изменения исходного кода.

Вот пример:

buttonListenerList << 
sourceButton->addButtonActionCallback(std::bind(&AudioSource::buttonCallback, this, _1, _2)); 

Этот мир кода определяется в общественном способе. Теперь AudioSource::buttonCallback - частный метод. Как вы можете вызвать этот частный метод, вызвав общедоступный метод.

+0

Вы можете поделиться некоторыми кодами? Его трудно полностью понять, о чем вы говорите без него. – Smeeheey

+0

Может ли sourceButton издеваться? Я имею в виду - это вводится в ваш класс через какой-то интерфейс? – PiotrNycz

+0

Ya, что можно насмехаться. Но используя это, как можно вызвать частную функцию? – Bharathi

ответ

2

Если вы ответили «да» в комментарии) sourceButton можно высмеять - тогда ожидание addButtonActionCallback называется - и сохраняет пройденный std::function<> arg.

Как и в примере, приведенном ниже (замените ... с реальными типами):

struct TestSuite : public ::testing::Test { 
    ... sourceButtonMock; 
    std::unique_ptr<...> objectUnderTest; 
    void SetUp() override; 
    std::function<...> sourceButtonActionCallback; 
}; 
using namespace ::testing; 
void TestSuite::SetUp() 
{ 
    EXPECT_CALL(sourceButtonMock, addButtonActionCallback(_)) 
      .WillOnce(SaveArg<0>(&sourceButtonActionCallback); 
    objectUnderTest = std::make_unique<...>(sourceButtonMock); 
} 

После хранить эту функцию обратного вызова в sourceButtonActionCallback переменной-члена - вы можете назвать это свободно везде, где вы хотите:

TEST_F(TestSuite, shallDo...OnSourceButtonClick) 
{ 
    // prerequisites 
    ASSERT_NE(sourceButtonActionCallback, nullptr); 

    // Expecteations 
    ... 

    // action 
    sourceButtonActionCallback(...); 

    // post-assertions 
    ... 
} 
0

В модульном тестировании вы не проверяете частные функции-члены, а только публичные.

У меня есть большой проект, который использует map со списком function s, которые имеют связанные с ними параметры. Я вызываю публичный метод с разными параметрами, которые, в свою очередь, вызывают различные функции на карте. Затем я могу проверить состояние ответа (коды ошибок, так как это многопоточность), чтобы проверить правильность поведения. Это то, что вы должны делать в своем сценарии.

Вызов общественной функции и проверка состояния в конце.

0

Думаю, вам нужно рассмотреть, что вы хотите проверить.

  • Если вы хотите, чтобы проверить, будет ли обратные вызовы вызывается, когда кнопка нажата, вам не нужно подвергать свои личные методы, на самом деле, вам не нужно делать это, так как кнопка «уже доказано». Когда кнопка нажата, вызываются связанные обратные вызовы.
  • Если вы хотите проверить, выполняют ли ваши частные функции то, что они должны, результат обратного вызова должен изменить какое-то состояние (которое может быть открыто через геттеры). Затем вам нужен способ вызвать событие кнопки, или вы можете использовать виртуальную функцию, которую можно открыть с помощью кнопки и теста.

Не видя код, его сложно комментировать дальше, но не пытайтесь проверить, работает ли кнопка (вызывает обратный вызов). Нет смысла там.

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