2015-07-09 10 views
4

У меня есть основной вопрос относительно Googletest в Eclipse.Googletest Eclipse C++: Как иметь тестовый и производственный исполняемый файл?

Я использую подключаемый модуль test-runner для запуска Googletests. Но мне нужно указать бинарный файл, который запускает свои тесты единиц (конечно, что имеет смысл.)

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

int main(int argc, char** argv) { 
    ::testing::InitGoogleTest(&argc, argv); 
    return RUN_ALL_TESTS(); 
} 

для запуска тестов Google.

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

Какую практику вы используете для лечения этой ситуации?

ответ

1

Googletest C++ - это модульная система тестирования. Это означает, что он предназначен для тестирования реализаций API C++. Он не предназначен для тестирования программ.

Для практических целей C++ API - это то, что вы получаете в заголовочном файле C++. Реализация такого API может быть реализована в :

  • Только сам заголовочный файл. (Реализация полностью рядная)
  • Файл заголовка плюс один ++ исходного файла C
  • Файл заголовка плюс связка C++ исходных файлов

обобщать, реализация C++ API является заголовком файл плюс 0 или более исходных файлов.

Скажите, что ваша программа my_prog вызывает API, который вы или ваша команда разработали для управления предметами. Реализация что-то вроде:

gizmo.h 
[gizmo_0.cpp,...gizmo_N.cpp] 

где [...] означает необязательно ...

Может my_prog полагается на других API, для которых вы или ваша команда ответственны, , но мы будем придерживаться только один , my_prog использует отмели API с помощью: -

  • Использование #include "gizmo.h" в некоторых исходных файлов.
  • Компиляция исходных файлов [gizmo_0.cpp,...gizmo_N.cpp], если они есть.
  • Ссылка на объектные файлы [gizmo_0.o,...gizmo_N.o], если они есть.

(gizmo_0.obj, etc.если вы на Windows)

Тестирования реализации гизм API с Googletest предполагается , чтобы подтвердить, что эта реализация является правильной, независимо от my_prog или любой другой программы, которая опирается на нее, чтобы управлять вещицами. Таким образом, включение блока-тестирование реализации в реализацииmy_prog ошибочна: -

Может быть, ваш коллега пишет другую программу, которая также должна управлять вещицы с этой реализацией. Возможно, вы напишите еще один. Кто-нибудь пишет эту программу , предполагающую повторить процесс включения в нее блок-тестов gizmo - Те же самые? Разные? - и сделать программу условно компиляции либо как тест-жгут gizmo, либо как все, что должно быть в реальной жизни?

А как вы знаете, что реализация штуковины не какая-то образом переплетаются с функциональности, которая уникальна для my_prog, или с реализацией какого- другого API, который my_prog использует таким же образом - так, что, когда вы или кто-то другой пытается повторно использовать его в другой программе, он ломается или ведет себя неправильно?

Никакая программа, которая опирается на эту реализацию gizmo, - это место, где нужно поставить его модульное тестирование. Изготовление my_prog условно скомпилировать различные функции main, чтобы он мог двойной в качестве жгута проводов для вашей библиотеки gizmo аналогичен разрезанию отверстия в промежности ваших джинсов для вашей головы.

Пути вы должны юнит-тест библиотека штуковины написать программу, которая является тест-Жгут для этой библиотеки, и ничего другого. Эта программа, скажем, gizmo_test, будет использовать API-интерфейс gizmo так же, как и любая другая программа, но с единственной целью тестирования библиотеки gizmo. Все это gizmo_test будет выполнять тесты библиотеки gizmo, вызывая его API.

В первом приближении, рецепт GoogleTest для gizmo_test является:

Написать заголовочный файл, gizmo_test.h

#include "gizmo.h" в нем

#include <gtest/gtest.h> в нем

Затем напишите ваши тестовые случаи Googletest в нем

Напишите следующее urce файл gizmo_test.cpp

#include "gizmo_test.h" 

int main(int argc, char** argv) { 
    ::testing::InitGoogleTest(&argc, argv); 
    return RUN_ALL_TESTS(); 
} 

Создать проект gizmo_test - в Eclipse, или любой другой среды разработки или построить систему вы используете - , которая строит gizmo_test исполняемый путем:

  • Компиляция исходных файлов gizmo_test.cpp + [gizmo_0.cpp,...gizmo_N.cpp]
  • Ссылка на результирующие файлы объектов gizmo_test.o + [gizmo_0.o,...gizmo_N.o], а также libgtest и любые другие библиотеки, на которых ваше gizmo l library зависит

У вас есть два проектов. Тот, который составляет my_prog, и тот, который составляет gizmo_test. В вашей среде разработки или постройте систему, сделайте сборку my_prog зависеть от сборки gizmo_test, чтобы при изменении всего, что влияет на , библиотека gizmo и перестройка my_prog, gizmo_test сначала перестраивается.

Это в первом приближении. Вы заметили какое-то время назад, что я начал говорить о вашей библиотеке ? Это то, что у вас есть (или должно быть) у . В C++ и программировании, как правило, реализация API называется библиотекой .

Возможно, вы также заметили некоторую хрупкость, неудобства и потери в рецепте для gizmo_test. У вас есть тот же набор исходных файлов gizmo [gizmo_0.cpp,...gizmo_N.cpp] в обоих проектах. Таким образом, вы можете редактировать, компилировать и связывать их по-разному в двух проектах. И они будут скомпилированы в обоих проектах, либо по-другому, , что неверно, или тождественно, что бессмысленно.

Конечно, если этот набор исходных файлов пуст - библиотека gizmo - это всего лишь gizmo.h - такой проблемы нет. Но если он не пуст, то есть .

Как известно, в C++ мы не используем библиотеку, создавая исходные файлы в каждой программе, которая ее использует, - если только она не является библиотекой только для заголовков. Библиотека построена сама по себе в объекте библиотека (статическая или динамическая), и для ее использования программа включает только заголовочный файл (ы) библиотеки и связывает библиотеку объектов.

Таким образом, программа также должна использовать вашу библиотеку gizmo.Таким образом, в окончательном приближении: -

  • сделать проект libgizmo, который строит библиотеку объектов штуковина (статический или динамический, как вы считаете нужным).
  • Сделать проект gizmo_test, как указано выше, за исключением того, что вместо компиляции и компоновки [gizmo_0.cpp,...gizmo_N.cpp], он просто связывает libgizmo, и сделать этот проект зависит от проекта libgizmo.
  • сделать проект my_prog, как у вас есть сейчас, но вместо компиляции и компоновки [gizmo_0.cpp,...gizmo_N.cpp], просто ссылку libgizmo, и сделать этот проект зависит от проекта gizmo_test.

Так у вас есть три проектов от времени вы строите первую программу, которая использует библиотеку отмели. Каждая последующая программа, использующая библиотеку gizmo, нуждается в одном проекте, например, my_prog.

Googletest предназначен для тестирования библиотек C++, и именно так вы должны использовать его.

Теперь я ничего не знаю о вашей программе или о том, как вы сейчас развертываете тестовые примеры Googletest в своем проекте. Возможно, там не являются четко определенными реализациями API в нем , которые должны выполнять те тестовые примеры, которые вы можете учитывать в отдельно стоящих библиотеках. Возможно, это может быть связано с тем, что ваша программа настолько проста, что модульное тестирование своих «компонентов» неприменимо, и вам было бы разумнее просто написать тесты на ядро ​​Blackbox. Скорее всего, это было бы потому, что вы до сих пор провалили , чтобы разработать программную архитектуру, которая может быть подвергнута единичному тестированию. Если это то, что вы нашли, вам нужно исправить его, а затем применить Googletest правильно. Это будет стоить усилий .

И в случае потребности отметил, блок-тесты не являются программы тесты, так как и блок-тестирования любых библиотек, ваша программа опирается на, если они ваша ответственность, вы также необходимость Blackbox испытания вашей программы.