LINUX.ORG.RU

Модный, годный православный mock/test для C++. Не gmock.

 , , ,


3

2

Есть чё? Желательно не прибитое к 11ому+.

Интересует штука, которая бы умела кейс с применением разных фикстур к одному тесту.

UPD. В принципе, собственно к gmock, я претензий особо не имею, важно что бы оно подружилось с сабжем, если он есть в природе :) А вот гуглотесты после питонячих меня сильно подразочаровали. Хотя казалось бы простое требование, которое запилить для компайл тайма не кажется сложным.

Что бы было понятней чего я жду от фрейма(хотя учитывая количество ответов, и что все они ведут на то, что я и так нагуглил - надеятся особо нечего):

struct FixtureA : ::testing::Test {
//setup/teardown
int a_;
};

struct FixtureB : ::testing::Test {
//setup/teardown
double a_;
};

bool test_method(void* data, size_t size);
TEST_MULTI_F(TestCase){//по идее тут обьявляется шаблонный класс
    ASSERT_TRUE(test_method(&a, sizeof(a)));
}

TEST_F(FixtureA, TestCase); // а тут он инстанируется
TEST_F(FixtureB, TestCase); // ну и тут
//как бэ почему не сделали так - непонятно
★★★★★

Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от eao197

Эта штука прибита к 11ому. Что уже не есть гуд, пока что.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от frugurt

Читануть - х3, может ниже покатит. Ну и мануал того же gmock.

На пальцах - удобный мок, это штука, которая даёт возможность сделать такую реализацию интерфейса, которая позволяет:

  • Контролировать из вне своё поведение
  • Уведомить о факте своего вызова, и принятых параметрах
  • Контроль и проверка факта вызова производятся из вне, в унифицированной форме

Для чего это нужно, пример, не самый жизненный, зато наглядный:

Допустим есть у тебя задача, запилить логику обработки некоего потока данных из некой железки. Ты знаешь что тебе шлются датаграммы размера X, содержащие данные структуры Y. Железка стоит 1ккк $, тебе её дадут потыкать раз в месяц и на финальных испытаниях, и то не тебе, а твоим манагерам.

Интерфейс железяки простой как валенок. И допустим тебя в основном колышет бизнесс логика.

Решение - отгораживаемся от железки интерфейсом типа:

struct MessageFormat;
struct Device {
virtual void getData(MessageFormat& data) = 0;
};

В тестах, на локальных испытаниях, при отладке, и везде везде используем условно такую реализацию:

struct DeviceMock : Device {
  DeviceMock(File* f) : file_(f){}
  void getData(MessageFormat& data) {
    file_.read(data.buf(), data.size());
    // на самом деле, тут должно быть контролируемое из вне поведение
  }
};

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

Помимо собственно удобства тестирования, при использовании TDD, чей не отьемлемой частью является mock, так же на низком уровне получаются более изолированные и лаконичные интерфейсы взаимодействия обьектов, с низким колличеством коммуникаций.

pon4ik ★★★★★
() автор топика
26 августа 2016 г.

Для тестов есть BOOST_TEST.

Раньше мне почему-то этот фреймворк очень не нравился, но это было субьективное мнение. Обьективно-же его fixture декораторы это красота и шик, лучше пока не видел для крестов.

Жалко только mockup нет из коробки.

pon4ik ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.