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

У меня есть основной вопрос относительно Googletest в затмении.

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

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

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

запустить тесты Google.

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

Но какую практику вы используете, чтобы справиться с этой ситуацией?

4

Решение

Googletest C ++ — это фреймворк для юнит-тестирования. Это означает, что он предназначен для тестирования
реализации API C ++. Не предназначен для тестирования программы.

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

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

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

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

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

где [...] средства по выбору …

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

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

(gizmo_0.objи т. д. если вы на винде)

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

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

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

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

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

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

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

#include "gizmo.h" в этом

#include <gtest/gtest.h> в этом

Тогда напишите свои тестовые случаи Googletest в этом

Напишите следующий исходный файл 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 и любые другие библиотеки, от которых зависит ваша библиотека гизмо

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

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

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

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

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

Вот так и программа должна использовать вашу библиотеку гизмо. Итак, до окончательного приближения: —

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

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

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

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

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

1

Другие решения


По вопросам рекламы [email protected]