Сравнение фреймворков модульного тестирования C++
Я знаю, что уже есть несколько вопросов относительно рекомендаций для фреймворков модульного тестирования C++, но все ответы не помогли, поскольку они просто рекомендуют одну из фреймворков, но не предоставляют никакой информации о сравнении (функций).
Я считаю, что наиболее интересными фреймворками являются CppUnit, Boost и новый фреймворк для тестирования Google. Кто-нибудь еще сравнивал?
У меня есть собственный фреймворк тестирования на основе IOC, который мне нравится больше, потому что он не просто клон того, что делают все остальные, но решает то, что я считаю всеми проблемами других. Вы пишете тестовые примеры, производя от класса, а не используя макросы. Макросы используются только для утверждений, поскольку они дают вам отражение. Настроенный вывод статистики тестирования. Запускайте из сценариев IOC, чтобы вы сами выбирали, что тестировать, как часто и с какими параметрами.
и это великолепно с точки зрения разработки, поскольку, когда я добавляю свой собственный тест, я могу запускать его без необходимости запускать все остальные одновременно. Итак, я знаю, что мой код работает.
Ответы 10
Посмотреть этот вопрос для обсуждения.
Они рекомендуют статьи: Изучение джунглей фреймворка модульного тестирования C++, Автор Ноэль Ллопис. И более свежий: Фреймворки тестовых модулей C++
Я еще не нашел статьи, сравнивающей googletest с другими фреймворками.
Как я уже писал: все ответы просто рекомендуют один из фреймворков, но не сравнивают фреймворк с другим.
Вы тоже недовольны статьей?
Одно замечание: статья, хотя и хорошая, датируется 2004 годом и не включает Google Test.
В первой ссылке вы увидите два сравнения. За исключением нового фреймворка от Google, большая часть информации по-прежнему актуальна (актуальна?). (И CppUnit это не самое интересное, это слишком топорно использования)
исправил ссылки и расширил ответ более свежим сравнением
Вторая ссылка не работает. Не могли бы вы это исправить?
Ответы не должны содержать только ссылку, чтобы что-то увидеть. Теперь в сообществе принято включать полную информацию, поскольку все ссылки станут недействительными в какой-то момент в течение великого вечного испытания временем, когда в какой-то момент все заканчивается и все начинается, включая нас и наших потомков.
В Википедии есть исчерпывающий список фреймворков модульного тестирования с таблицами, в которых указаны поддерживаемые функции или нет.
Есть некоторые соответствующие ресурсы для модульного тестирования C++ по адресу http://www.progweap.com/resources.html
Новый игрок - Google Test (также известный как Платформа тестирования Google C++), что довольно неплохо.
#include <gtest/gtest.h>
TEST(MyTestSuitName, MyTestCaseName) {
int actual = 1;
EXPECT_GT(actual, 0);
EXPECT_EQ(1, actual) << "Should be equal to one";
}
Основные особенности:
- Портативный
- Фатальный и несмертельные утверждения
- Простые информативные утверждения Сообщения:
ASSERT_EQ(5, Foo(i)) << " where i = " << i; - Google Test автоматически обнаруживает ваши тесты и не требует их перечисления для запуска.
- Упростите продлевать свой словарь утверждений
- Смертельные испытания (см. Расширенное руководство)
SCOPED_TRACEдля циклов подпрограмм- Вы можете решить какие тесты запускать
- XML генерация отчета об испытаниях
- Светильники / Насмехаться / Шаблоны ...
Мне очень нравится использовать тест Google поверх некоторых других фреймворков, особенно с его возможностями имитации, которые можно найти в фреймворке googlemock.
Я предоставляю все эти функции (хотя некоторые еще не являются общедоступными) и многое другое в моей новой тестовой среде CATCH. См. Мой ответ по ссылке.
объединение его вместе с Google C++ Mocking framework делает его действительно мощным тестовым фреймворком xUnit для модульного тестирования кода C++.
@CashCow Запуск со сборкой отличается от тестового обнаружения. Запуск со сборкой зависит от вашей системы сборки. Обнаружение тестов означает, что вы не имеют перечислите все тесты в другом классе, просто создайте методы тестов и все.
Однако мне не нравится их чрезмерное использование макросов и тот факт, что используются общие слова, такие как ТЕСТ, которые могут с чем-то конфликтовать. GTEST был бы лучше, меньше шансов столкнуться.
@CashCow Я бы сохранил вкусы за пределами SO (и вы можете переименовать, если действительно хотите). Я признаю, что макросы уродливы, но, вероятно, это неизбежное зло в C++ для поддержки всех функций без кода шаблонов.
Под кодом Scaffolding вы имеете в виду, что происходит от их классов, фактически вводя их имена? Что в этом плохого. Вот как вы обычно используете API, и это четкое указание на то, что вы делаете. Макросы полезны для отражения в утверждениях и для добавления ФАЙЛ и ЛИНИЯ за вас. Однако совершенно не интуитивно понятно, что означают TEST и TEST_F, и эти вещи не работают, если вы сделаете их неправильно. Например, могу ли я использовать их утверждения в бесплатных функциях, вызываемых из моих тестовых функций?
@CashCow Помните, что C++ не имеет отражения, которое есть в большинстве языков. Я предлагаю вам связаться со мной напрямую по электронной почте / через мгновенное сообщение, чтобы мы могли обсудить более подробную информацию, если хотите.
Я знаю, что C++ не имеет отражения, и поэтому макросы полезны для утверждений. Я написал тестовую библиотеку. Он использует внедрение зависимостей, как и GTEST. В нем есть макросы для утверждений, но не для чего-либо еще, а в API есть класс Predicate. Макросы здесь для удобства. Вы должны #include их заголовок, чтобы использовать их, они не включены для вас.
Я поддерживаю это. В настоящее время используется Boost.Test и страдает от отсутствия дополнительных операций assert и способа правильного вывода файлов xml, соответствующих xUnit, для хорошей интеграции с TeamCity.
Библиотека ускоренных тестов - очень хороший выбор, особенно если вы уже используете Boost.
// TODO: Include your class to test here.
#define BOOST_TEST_MODULE MyTest
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_CASE(MyTestCase)
{
// To simplify this example test, let's suppose we'll test 'float'.
// Some test are stupid, but all should pass.
float x = 9.5f;
BOOST_CHECK(x != 0.0f);
BOOST_CHECK_EQUAL((int)x, 9);
BOOST_CHECK_CLOSE(x, 9.5f, 0.0001f); // Checks differ no more then 0.0001%
}
Он поддерживает:
- Автоматический или ручная регистрация тестов
- Множество утверждений
- Автоматическое сравнение коллекции
- Различные форматы вывода (включая XML)
- Светильники / Шаблоны ...
PS: Я написал об этом статью, которая может помочь вам начать работу: C++ Unit Testing Framework: Учебное пособие по тестированию на ускорение
Раньше я использовал тест Boost, и он мне понравился, за исключением того, что, похоже, он значительно изменился между выпусками. Было достаточно сложно продать модульное тестирование моему клиенту, не тратя больше времени (и своих денег) на исправление тестов при изменении API, чем на исправление кода, который он должен был тестировать. В конце концов, я отбросил это и написал свой - хотя это было лет 5 назад.
Я только что выпустил свой собственный фреймворк ЛОВИТЬ. Он все еще находится в стадии разработки, но я считаю, что он уже превосходит большинство других фреймворков. У разных людей разные критерии, но я попытался охватить большую часть вопросов без особых компромиссов. Взгляните на мою связанную запись в блоге для дегустатора. Мои пять основных функций:
- Только заголовок
- Автоматическая регистрация тестов на основе функций и методов
- Разлагает стандартные выражения C++ на LHS и RHS (поэтому вам не нужно целое семейство макросов assert).
- Поддержка вложенных секций в приспособлении на основе функций
- Именные тесты с использованием естественного языка - генерируются имена функций / методов
Он также имеет привязки Objective-C. Проект размещен на Github
Пожалуйста, подумайте о добавлении макросов CHECK_FLASE и REQUIRE_FLASE.
На мой взгляд, лучший фреймворк.
@einpoklum Catch не заброшен - создатель работает над второй версией библиотеки. doctest - это своего рода повторная реализация Catch 1 с некоторыми дополнительными дизайнерскими решениями.
Я действительно не понимаю, когда сравниваю все тестовые фреймворки (одну из которых мне теперь нужно выбрать). Не могли бы вы написать свой собственный ответ, сравнивая и сравнивая doctest с Catch и другими предложениями?
@einpoklum Я бы сделал, если бы мог - но вопрос закрыт как not constructive, и я могу написать только комментарий ...
Проверка работоспособности API - тестовая среда для библиотек C / C++:
An automatic generator of basic unit tests for a shared C/C++ library. It is able to generate reasonable (in most, but unfortunately not all, cases) input data for parameters and compose simple ("sanity" or "shallow"-quality) test cases for every function in the API through the analysis of declarations in header files.
The quality of generated tests allows to check absence of critical errors in simple use cases. The tool is able to build and execute generated tests and detect crashes (segfaults), aborts, all kinds of emitted signals, non-zero program return code and program hanging.
Уникальные возможности по сравнению с CppUnit, Boost и Google Test:
- Автоматическое создание тестовых данных и входных аргументов (даже для сложных типов данных)
- Современный и многоразовый специализированные типы вместо приспособлений и шаблонов
CppUTest - очень красивый, легкий фреймворк с макетными библиотеками. Стоит присмотреться.
CPUnit (http://cpunit.sourceforge.net) - это фреймворк, похожий на Google Test, но использующий меньшее количество макросов (утверждения - это функции), и где макросы имеют префиксы, чтобы избежать обычной ловушки макросов. Тесты выглядят так:
#include <cpunit>
namespace MyAssetTest {
using namespace cpunit;
CPUNIT_FUNC(MyAssetTest, test_stuff) {
int some_value = 42;
assert_equals("Wrong value!", 666, some_value);
}
// Fixtures go as follows:
CPUNIT_SET_UP(MyAssetTest) {
// Setting up suite here...
// And the same goes for tear-down.
}
}
Они автоматически регистрируются, поэтому вам не нужно больше этого. Затем он просто компилируется и запускается. Я считаю, что использование этой структуры очень похоже на использование JUnit для тех, кому пришлось потратить некоторое время на программирование на Java. Очень хорошо!
Недавно я выпустил xUnit ++, в частности, как альтернативу Google Test и библиотеке Boost Test (см. сравнения). Если вы знакомы с xUnit.Net, вы готовы к xUnit ++.
#include "xUnit++/xUnit++.h"
FACT("Foo and Blah should always return the same value")
{
Check.Equal("0", Foo()) << "Calling Foo() with no parameters should always return \"0\".";
Assert.Equal(Foo(), Blah());
}
THEORY("Foo should return the same value it was given, converted to string", (int input, std::string expected),
std::make_tuple(0, "0"),
std::make_tuple(1, "1"),
std::make_tuple(2, "2"))
{
Assert.Equal(expected, Foo(input));
}
Основные особенности:
- Невероятно быстро: тесты запускают одновременно.
- Портативный
- Автоматический тестовая регистрация
- Типы утверждений Много (Boost не имеет ничего общего с xUnit ++)
- Сравнивает коллекции изначально.
- Утверждения имеют уровни три:
- фатальные ошибки
- нефатальные ошибки
- предупреждения
- Легкое ведение журнала утверждать:
Assert.Equal(-1, foo(i)) << "Failed with i = " << i; - Тестовое задание логирование:
Log.Debug << "Starting test"; Log.Warn << "Here's a warning"; - Светильники
- На основе данных тесты (теории)
- Выберите тесты для запуска на основе:
- Соответствие атрибутов
- Соответствие подстроки имени
- Наборы тестов
Вопрос для сравнения. IMO, важно представить, каковы различия между вашим фреймворком и, по крайней мере, двумя популярными: googletest и Boost. Особенно, если вы рекламируете xUnit ++ как альтернативу этим двум. Будет +1, если обновится :)
Справедливо. :) У меня уже есть Сравнительная таблица на вики, но я постараюсь подытожить некоторые отличия прямо в своем ответе.
Я решил просто связать вики-таблицу напрямую, она загромождала сводку, чтобы перечислить все это.
ссылка у меня работает, спасибо! +1
Также написано на макроязыке. Что плохого в использовании C++ вместо макросов FACT и THEORY?
Лично я очень ненавижу макросы. Я подумывал о написании версии 2.0 с использованием вызовов методов и лямбда-выражений, я просто не пишу на C++ в наши дни и до этого не дошел.
ваш проект был прекращен? Последний коммит датируется 09/2015 ... В любом случае, отличный ответ. Спасибо.
возможный дубликат Модульное тестирование кода C++ - Инструменты и методология