Выложил свой любительский перевод статьи Exploring the C++ Unit Testing Framework Jungle, в которой ставниваются фреймворки:

CppUnit
Boost.Test
CppUnitLite
NanoCppUnit
Unit++
CxxTest

Сравнение осуществяется с учетом таких аспектов как:

Минимальное количество работы, требуемое для создания нового теста
Простота в модификации и портировании
Поддержка установки/удаления шагов
Хорошая обработка исключений и крешей
Хорошая функциональность ASSERT
Поддержка различных методов вывода информации
Поддержка TestSuit'ов

Надеюсь статья окажется кому то полезной.

Перевод читать здесь

Здравствуйте, sharcUs, Вы писали:

U>Выложил свой любительский перевод статьи Exploring the C++ Unit Testing Framework Jungle, в которой ставниваются фреймворки:

U>Надеюсь статья окажется кому то полезной.

U>Перевод читать здесь

Я так понимаю, мы должны оценивать перевод, а не саму статью?

Статья сильно устарела — в Boost.Test уже давно есть встроенная поддержка и тест-сьютов, и фикстур (установщиков)

И самое главное, что почему-то не упомянуто в статье — это то, что в Буст.Тесте есть параметрические и шаблонные тесты.

You will always get what you always got
  If you always do  what you always did

Самое главное чего там не хватает: автор впоследствии написал UnitTest++. Сейчас я бы выбирал только между этим фреймворком и Boost.Test.

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, sharcUs, Вы писали:

U>>Выложил свой любительский перевод статьи Exploring the C++ Unit Testing Framework Jungle, в которой ставниваются фреймворки:

U>>Надеюсь статья окажется кому то полезной.

U>>Перевод читать здесь

J>Я так понимаю, мы должны оценивать перевод, а не саму статью?

J>Статья сильно устарела — в Boost.Test уже давно есть встроенная поддержка и тест-сьютов, и фикстур (установщиков)

J>И самое главное, что почему-то не упомянуто в статье — это то, что в Буст.Тесте есть параметрические и шаблонные тесты.

А еще в boost.test есть такие макросы как:

BOOST_CHECK_EQUAL_COLLECTION
BOOST_CHECK_PREDICATE

Немного поработав напильником, я сделал BOOST_CHECK_EQUAL_RANGE. Теперь, в связке с boost.assign, можно писать очень короткие и выразительные тесты:

using namespace boost::assign;

std::vector<int> v = list_of(5)(2)(1)(3)(4);
std::sort(v.begin(), v.end());

BOOST_CHECK_EQUAL_RANGE(v, list_of(1)(2)(3)(4)(5));

Здравствуйте, Adriano, Вы писали:

A>Немного поработав напильником, я сделал BOOST_CHECK_EQUAL_RANGE.

+1

Я думаю, у каждого много таких маленьких радостей в проекте

You will always get what you always got
  If you always do  what you always did

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Я думаю, у каждого много таких маленьких радостей в проекте

Например, вот такие простенькие, но полезные девайсы сделал я:

1) XXX_CHECK_STR_EQUAL — сравнивает две строки и показывает место, где они разошлись (примерная реализация для однострочных строк ниже, в реальности все сложнее, ибо больше всяких мелких дополнительных фич):

template <class S1, class S2>
std::ptrdiff_t seq_mismatch_pos(const S1& s1, const S2& s2)
{
  return std::mismatch( boost::begin(s1)
                      , boost::begin(s1) + std::min( boost::size(s1), boost::size(s2) )
                      , boost::begin(s2)
                      ).first - boost::begin(s1);
}

#define XXX_TEST_STR_EQUAL(test, s1, s2)              \
  BOOST_##test##_MESSAGE( s1 == s2,                   \
    "String comparison failed at position "           \
    << seq_mismatch_pos( s1, s2 ) << ": \n"           \
    << s1 << '\n' << s2 << "\n"                       \
    << std::string( seq_mismatch_pos( s1, s2 ), ' ' ) \
    << '^'                                            \
  );

#define XXX_CHECK_STR_EQUAL(   s1, s2 ) XXX_TEST_STR_EQUAL( CHECK,   s1, s2 )
#define XXX_WARN_STR_EQUAL(    s1, s2 ) XXX_TEST_STR_EQUAL( WARN,    s1, s2 )
#define XXX_REQUIRE_STR_EQUAL( s1, s2 ) XXX_TEST_STR_EQUAL( REQUIRE, s1, s2 )

///////////////////////
XXX_CHECK_STR_EQUAL( "asd12345", "asd54321" );
/*
Output:
test.cpp:522: error in "test_str": String comparison failed at position 3:
asd12345
asd54321
   ^
*/

Ну и аналогичная тестилка для коллекций, написанная примерно так же, как seq_mismatch_pos (думаю, твоя написана точно так же).

2) WhatIs — для тестирования того, что возвращает метод what() исключения:

struct WhatIs
{
  const std::string s_;
  explicit WhatIs(const std::string& s) : s_(s) {}
  bool operator()(const std::exception& e) const { return e.what() == s_; }
};

///////////////////////
void f(int i) { if (i==0) throw std::runtime_error("0 is not allowed"); }
BOOST_CHECK_EXCEPTION( f(0), MyException, WhatIs("0 is not allowed") );

3) XXX_CHECK_NO_THROW — распечатает исключение, которое бросилось (в отличие от BOOST_CHECK_NO_THROW, который просто печатает факт того, что исключение было брошено, и всё):

#define XXX_TEST_NO_THROW(test, a) \
  try { a; }                       \
  catch (...)                      \
  {                                \
    BOOST_##test##_MESSAGE( false, \
      "exception thrown by " #a    \
      << ExceptionPrinter()        \
    );                             \
  }

#define XXX_CHECK_NO_THROW(   a ) XXX_TEST_NO_THROW( CHECK,   a )
#define XXX_WARN_NO_THROW(    a ) XXX_TEST_NO_THROW( WARN,    a )
#define XXX_REQUIRE_NO_THROW( a ) XXX_TEST_NO_THROW( REQUIRE, a )

///////////////////////
void f(int i) { if (i==0) throw std::runtime_error("0 is not allowed"); }
XXX_CHECK_NO_THROW( std::cout, f(0) );
/*
Output:
test.cpp:523: error in "test_excepton": exception thrown by f(0): 0 is not allowed
*/

где ExceptionPrinter — довольно хитрый класс (заточенный под наш проект и наши исключения, печатающий стек и прочая) и целиком я его приводить не буду, но в общих чертах — у него есть operator<<, который делает примерно следующее:

std::ostream& operator<<(std::ostream& os, const ExceptionPrinter&)
{
  try {
    throw;
  }
  catch (const std::exception& e)
  {
    os << e.what();
  }
  catch (...)
  {
    os << "(unknown exception)";
  }
}

понятно, что тут можно насовать много дополнительных catch и прочего, специфичного для Вашего проекта.

PS Замените XXX на префикс, принятый для макросов в Вашем проекте. Помните о глобальности имен макросов!
PPS Коллеги, ждем Ваших хелперов!

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:
Так то оно так, но что то непохоже что сильно много чего изменилось с тех пор, как мне кажется...
Вот про буст дописали, рассказали — хорошо...
А с другими фреймворками как будто никто и не работает?

В Overload два года назад еще писали про Fructose: FRUCTOSE &mdash; a C++ Unit Test Framework, но что то ничего не слышно больше про фреймворк с той поры.
А еще номером позже сравнение сделали Boost.test, Aeryn, FRUCTOSE и CxxTest. C++ Unit Test Frameworks
Для интересующихся, статьи могут оказаться также полезными.

Здравствуйте, sharcUs, Вы писали:

U>Здравствуйте, jazzer, Вы писали:
U>Так то оно так, но что то непохоже что сильно много чего изменилось с тех пор, как мне кажется...
U>Вот про буст дописали, рассказали — хорошо...
U>А с другими фреймворками как будто никто и не работает?

Ну я с чем работаю, про то и написал.
Кто использует остальное — пусть пишут про свои.

А если не пишут — так можно просто зайти на сайт каждого и посмотреть, что изменилось с 2004 года.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, sharcUs, Вы писали:

U>В Overload два года назад еще писали про Fructose: FRUCTOSE &mdash; a C++ Unit Test Framework, но что то ничего не слышно больше про фреймворк с той поры.
U>А еще номером позже сравнение сделали Boost.test, Aeryn, FRUCTOSE и CxxTest. C++ Unit Test Frameworks
U>Для интересующихся, статьи могут оказаться также полезными.


Спасибо за ссылку, напишу про Буст.Тест:

We would have used Boost, except our compiler limited us to the header only libraries.

поддержка режима "только хедеры" есть (и в то время она тоже была, видимо, человек ее не нашел в документации просто).

Boost does not support selecting tests from the command line.

Уже поддерживает, опция --run_test

It doesn't have _LT, _LE, _GT, _GE variants

Тоже уже есть.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, sharcUs, Вы писали:
U>Выложил свой любительский перевод статьи Exploring the C++ Unit Testing Framework Jungle, в которой ставниваются фреймворки
Спасибо, sharcUs, за перевод хорошей и полезной статьи на русский язык!

Здравствуйте, skeptik_, Вы писали:

_>Самое главное чего там не хватает: автор впоследствии написал UnitTest++. Сейчас я бы выбирал только между этим фреймворком и Boost.Test.

А какие у него преимущества перед Буст.Тест?
Я вижу только проверку времени, которой нет в буст.тесте, но мне лично она не особо нужна в таком виде, потому что я обычно вывожу затраченное время, и частенько делю его на количество итераций/элементов и т.п, чтоб знать (и сравнивать с эталоном) время именно одной итерации. Ну и плюс очень неудобно рожать по области видимости каждый раз (сейчас я просто делаю таймеру reset в любом месте теста).
Ну и в некоторых конторах буст запрещен по религиозным соображениям , так что для них это может быть спасением.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, skeptik_, Вы писали:

_>>Самое главное чего там не хватает: автор впоследствии написал UnitTest++. Сейчас я бы выбирал только между этим фреймворком и Boost.Test.

J>А какие у него преимущества перед Буст.Тест?
J>Ну и в некоторых конторах буст запрещен по религиозным соображениям , так что для них это может быть спасением.

Именно. Но я лично выбираю Boost.Test.

Здравствуйте, sharcUs, Вы писали:

U>Выложил свой любительский перевод статьи Exploring the C++ Unit Testing Framework Jungle, в которой ставниваются фреймворки:

U>Надеюсь статья окажется кому то полезной.

U>Перевод читать здесь

статья в свое время была уникальной — так что ваш труд по ее переводу не пропадет.

От себя хочу добавить что список тестовых либ не ограничивается бустом я вот давно (с vs71) использую TUT. Его достоинство — одни хидеры и нет макросов.

Забавную либу недавно сделал гугль (они рассчитаны на мобильники и тп ограниченные среды). Впрочем имхо забавное там только использование цвета в консоли.

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, jazzer, Вы писали:

J>>Я думаю, у каждого много таких маленьких радостей в проекте

J>Например, вот такие простенькие, но полезные девайсы сделал я:

Do you have anything that might be generally useful and thus can be added to the Boost.Test itself?

Gennadiy

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, skeptik_, Вы писали:

_>>Самое главное чего там не хватает: автор впоследствии написал UnitTest++. Сейчас я бы выбирал только между этим фреймворком и Boost.Test.

J>А какие у него преимущества перед Буст.Тест?
J>Я вижу только проверку времени, которой нет в буст.тесте,

Some kind of profiler was in plans, but I do not have enough time lately to implement all I have in mind.
Gennadiy

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, sharcUs, Вы писали:

U>>В Overload два года назад еще писали про Fructose: FRUCTOSE &mdash; a C++ Unit Test Framework, но что то ничего не слышно больше про фреймворк с той поры.
U>>А еще номером позже сравнение сделали Boost.test, Aeryn, FRUCTOSE и CxxTest. C++ Unit Test Frameworks
U>>Для интересующихся, статьи могут оказаться также полезными.


J>Спасибо за ссылку, напишу про Буст.Тест:
J>

J>We would have used Boost, except our compiler limited us to the header only libraries.

J>поддержка режима "только хедеры" есть (и в то время она тоже была, видимо, человек ее не нашел в документации просто).

J>

J>Boost does not support selecting tests from the command line.

J>Уже поддерживает, опция --run_test

J>

J>It doesn't have _LT, _LE, _GT, _GE variants

J>Тоже уже есть.

Also I'd like to remark that:

1. Boost.Test does not require latest compiler. It works with majority of current compilers out of the box.
2. Boost.Test does support custom output formats.

Gennadiy

Здравствуйте, sharcUs, Вы писали:

U>Выложил свой любительский перевод статьи Exploring the C++ Unit Testing Framework Jungle, в которой ставниваются фреймворки:

U>

U>CppUnit
U>Boost.Test
U>CppUnitLite
U>NanoCppUnit
U>Unit++
U>CxxTest
U>

U>Сравнение осуществяется с учетом таких аспектов как:

U>

U>Минимальное количество работы, требуемое для создания нового теста
U>Простота в модификации и портировании
U>Поддержка установки/удаления шагов
U>Хорошая обработка исключений и крешей
U>Хорошая функциональность ASSERT
U>Поддержка различных методов вывода информации
U>Поддержка TestSuit'ов
U>

U>Надеюсь статья окажется кому то полезной.

U>Перевод читать здесь

Date
December 28th, 2004

зачем переводить такое старье?

Здравствуйте, Adriano, Вы писали:

A>Немного поработав напильником, я сделал BOOST_CHECK_EQUAL_RANGE.

А имя-то зачем как у "настоящего"? У макросов нет пространств имен, и BOOST_ в имени макроса выполняет роль имени пространства имен. Или ты и свои классы и функции в пространство имен boost помещаешь?

Здравствуйте, rogeeff, Вы писали:

...

J>>>Я думаю, у каждого много таких маленьких радостей в проекте

J>>Например, вот такие простенькие, но полезные девайсы сделал я:

R>Do you have anything that might be generally useful and thus can be added to the Boost.Test itself?

Обновленная документация была-бы very generally useful. Последний раз обновлялась в 2007. С тех пор вышло несколько версий, глюки правились, новая функциональность добавилась. В release notes — ни слова. Сколько времени test_unit::depends_on без документации?