Как проверить EXE с помощью Google Test?

зависит. Google Test-это (в первую очередь) платформа модульного тестирования (упрощение, тестирование классов). Вы можете абсолютно использовать is для других типов тестов, но у него нет "встроенной" функциональности для других типов тестирования, вам придется написать ее самостоятельно.

Если вы пытаетесь протестировать исполняемый файл, вы можете запустить процесс. Я предлагаю использовать Boost.Процесс, если вы используете многоплатформенную систему или уже имеете зависимость boost. Еще посмотри здесь: запустить exe / процесс с stdin stdout и stderr?

" тесты", которые вы пишете, будут вызывать исполняемый файл и могут вводить stdin или stdout соответственно.

например:

std::string path_to_exectuable = "thepath";
TEST(FooTester,CheckHelpScriptReturns0)
{
 using bp =::boost::process; 
 std::vector<std::string> args; args.push_back("--help");
 bp::context ctx; 
 ctx.stdout_behavior = bp::capture_stream(); 

 bp::child c = bp::launch(exec, args, ctx); 
 bp::status s = c.wait(); 
 ASSERT_TRUE(s.exited())<<"process didn't exit!";
 ASSERT_EQ(s.exit_status(),0)<<"Help didn't return 0";
}

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

то, что я сделал, это создать пользовательскую конфигурацию, которую я назвал "тестирование". Вы создаете новую конфигурацию, открывая параметры проекта, выбрав " Configuration Manager..."и выбрав "новый..."в выборе конфигурации коробка.

при появлении запроса я решил скопировать настройки из конфигурации "Debug" по умолчанию, чтобы я мог использовать отладчик с моими тестами так же, как если бы я был в конфигурации "Debug".

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

важным изменением свойств является то, что я определяю переменную препроцессора, которую я назвал "тестирование".

I переписал мой "главный.cpp", чтобы выглядеть примерно так:

...
// includes
// functions
// whatever
...

#ifdef TESTING
#include <gtest/gtest.h>
#endif

int main(int argc, char **argv) {
   #ifdef TESTING
   ::testing::InitGoogleTest(&argc, argv);
   int val = RUN_ALL_TESTS();
   getchar();  // not necessary, but keeps the console open
   return val;
   #endif    

   // rest of main() as normal...
}

то, что я пытаюсь указать, это то, что я изменил только несколько строк вокруг того, где main определено, мне не нужно делать грубые изменения, распространяющиеся по всему файлу.

теперь, когда все это настроено, я просто сделал новую исходную папку для своих тестов и создал ".cpp " файлы там. Чтобы избежать раздувания обычного исполняемого файла, я обертываю эти файлы с проверкой переменной тестирования, поэтому у меня есть что-то вроде это:

tests/Test.cpp:

#ifdef TESTING

#include <gtest/gtest.h>

#include "my_class_header.h"

TEST(TestMyClass, test_something) {
    // perform some test on class
} 

#endif

Я думаю, что эти файлы по-прежнему "попадают" компилятором в конфигурации отладки и выпуска, поэтому их тонна может замедлить сборку, но объекты отладки и выпуска не будут раздуваться с помощью тестового кода.

два выноса:

• используя этот метод, код тестирования по-прежнему организован отдельно от кода приложения, но он по-прежнему находится в том же проекте Visual Studio, который может быть полезным, а может и нет. Лично мне нравится не управлять/беспокоиться о втором проекте.
• как Майк Kinghan сказал, управление и связывание .obj файлы сами могут стать рутиной, но с помощью этого метода настройки Visual Studio по умолчанию управляют этим для вас.

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

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

Если вы хотите протестировать консольное приложение, вы можете запустить тест, который открывает окно консоли и запускает exe-файл первого приложения. Затем в вашем googletest поймать стандартный вывод из exe вы только что побежали.

[для большего контроля над первым приложением вам может потребоваться отправить ему первые аргументы синтаксического анализа приложения, например, некоторые флаги, такие как-x или что вам нужно.]

Я подготовил РЕПО github, включая решение Visual Studio 2015, в parralel предложения Майка "drill-sergeant". Вы можете использовать его напрямую без каких-либо дополнительных условий или зависимости.

https://github.com/fuatcoskun/GoogleTestVS2015

надеюсь, это поможет...

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

int main(int argc, char* argv[])
{
    if (argc >= 2 && std::string(argv[1]) == "--tests")
    {
        ::testing::InitGoogleTest(&argc, argv);
        return RUN_ALL_TESTS();
    }
    else
    {
        // Application logic goes here
    }
}

TEST(ExampleTests, TestSQRTCalculation) // assuming all the right headers are included
{
    EXPECT_NEAR(2.0, std::sqrt(4.0), 0.000001);
}

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

отладка тестов или их автоматический запуск в post build легко, просто указав "--tests " как debug args или в командной строке post build соответственно.