#c #testing #boost
Вопрос:
Я испытываю разочарование при тестировании с помощью Boost, и мне интересно, есть ли более чистый/лучший способ справиться с этим.
У меня есть некоторый метод myFunc (), который является частью MyClass.
- myFunc() действительно должен быть частным — он предназначен только для внутреннего использования MyClass, больше ничего не нужно знать об этом или использовать.
- Я должен проверить myFunc(). Это небольшая, но важная часть более крупного класса. Если это не удается, функциональность класса неверна для некоторых применений.
Однако именно здесь мы сталкиваемся с проблемой:
- Тестовые случаи повышения (настроенные с
BOOST_AUTO_TEST_SUITEBOOST_AUTO_TEST_CASEпомощью, и т.д.) Не могут получить доступ к закрытым участникам
Итак, я знаю только о двух вариантах, оба одинаково уродливы по разным причинам:
- Сделайте функцию общедоступной. Это будет сбивать с толку тех, кто смотрит на класс, так как они подумают, что myFunc() может быть чем-то, что они могли бы использовать внешне, даже если этого не следует делать.
- Вызовите один из немногих общедоступных методов, предлагаемых MyClass, таким образом, чтобы вызывалась функция myFunc (), и посмотрите на результаты. По нескольким причинам это полный бардак. Это требует значительно большей настройки в тесте, потому что эти методы делают больше, чем просто то, что делает myFunc (). Это также означает, что если в другом месте кода возникла проблема, это может привести к сбою теста myFunc (), даже если на самом деле все в порядке. Наконец, мне, возможно, потребуется добавить дополнительные общедоступные методы для получения состояния класса, чтобы я знал достаточно, чтобы сказать, является лиmyFunc() работал правильно или нет — поэтому, в конце концов, я добавляю больше общедоступных методов, которые в любом случае никто другой не должен вызывать.
В C есть концепция friend , но поскольку это всего лишь файл .cpp со многими BOOST_AUTO_TEST_CASE внутри, нет никакого класса, с которым можно подружиться.
Я уверен, что другие сталкивались с этим раньше, когда использовали Boost для тестирования. Какие еще существуют решения?
Комментарии:
1. При всем уважении, детали реализации тестирования (частные лица) — это тестирование, выполненное неправильно. Это неправильное разделение для единиц измерения (в чем суть модульного тестирования). Проверьте поведение класса и выберите тестовые случаи, в которых используется этот закрытый член. Используйте инструменты покрытия, чтобы точно указать их. Затем, если вам нужно изменить детали реализации, тесты все равно передают смысл.
2. Лично я с этим не согласен. Это делает модульные тесты в нашем случае довольно раздутыми по размеру, их сложнее поддерживать при изменении кода, они медленнее запускаются и, в конце концов, требуют больше ненужных общедоступных методов для получения состояния, которое мне нужно было бы проверить, верны ли результаты. Я думаю, что тесты-это хорошее место, чтобы хотя бы немного «нарушить» правила конвенции, поскольку они не являются частью основного кода.