Указание тестовых зависимостей в CppUnit?

Хочу уточнить порядок тестирования в CppUnit. Согласно моим исследованиям, порядок тестирования зависит от компилятора или компоновщика и от того, как они находили файлы.

Как указать зависимости в CppUnit?

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

struct Point
{
  int x;
  int y;
};

struct Line
{
  Point a;
  Point b;
};

struct Rectangle
{
  Line top;
  Line left;
  Line right;
  Line bottom;
};

В приведенном выше коде сначала следует протестировать класс Point, затем класс Line и, наконец, класс Rectangle. Нет причин тестировать класс Rectangle, если у классов Line или Point есть проблемы. Это очень упрощенный пример.

Для составных классов сначала следует тестировать внутренние классы или классы типов данных-членов.

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

Итак, как упорядочить тестовые примеры?

К вашему сведению, я использую CppUnit, wxTestRunner и Visual Studio 2008


person Thomas Matthews    schedule 19.06.2010    source источник


Ответы (1)


То, что вы пытаетесь сделать, на самом деле не является модульным тестированием. «Чистое» модульное тестирование предназначено для тестирования отдельных модулей (отдельных классов) с использованием имитаций или поддельных объектов вместо реальных зависимостей; когда вы тестируете зависимости классов друг от друга, это интеграционное тестирование, а не модульное тестирование.

С этим отказом от ответственности ...

Похоже, вы могли бы использовать CPPUNIT_TEST_SUITE_NAMED_REGISTRATION для создания нескольких наборов затем запустите каждый пакет по порядку, только если все предыдущие пакеты прошли, но для этого вам может потребоваться взломать или заменить средство запуска тестов wxTestRunner.

На странице CppUnit Создание TestSuite есть другие варианты регистрации наборов тестов; CPPUNIT_REGISTRY_ADD, например, позволяет создавать иерархию наборов, которые должен дать вам некоторый контроль над порядком, но я не вижу возможности для отказа в одном пакете прервать последующие тесты.

Наконец, просто в качестве предположения, CppUnit, вероятно, не лучшая среда для модульного тестирования C ++ в наши дни. Я лично поклонник Google Test, но Boost.Test и UnitTest ++ тоже хороши. (Этот ответ представляет личный проект под названием Saru, который звучит так, как будто он может дать вам гибкость, которую вам нужно при заказе тестов.)

person Josh Kelley    schedule 19.06.2010
comment
Во многих случаях я не думаю, что модульное тестирование, о котором вы говорите в первом абзаце, применимо к C ++. Чтобы провести такое тестирование, вы действительно должны иметь возможность внедрять имитацию в систему, а это становится довольно проблематичным с типами значений. В примере с OP здесь я бы сказал, что у этих классов нет поведения для тестирования. - person Edward Strange; 19.06.2010
comment
@Noah: Библиотеки вроде Google Mock помогают, но вы правы, это тот случай где практичность важнее чистоты теории. (ОП отметила, что это очень упрощенный пример.) - person Josh Kelley; 19.06.2010