0

I modified one of the answers here like

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("myExe.exe", args, ctx); 
 EXPECT_EXIT(c.terminate(), ::testing::ExitedWithCode(0), "");
}

in the hope to make it more straightforward. However, this wont work,and will output

Result: failed to die

So, is this approach possible at all, and if yes, what is missing?

Community
  • 1
  • 1
HeinrichStack
  • 694
  • 3
  • 8
  • 28

1 Answers1

1

The macros ASSERT/EXPECT_EXIT(statement, predicate, regex) are satisified when:-

  • Execution of statement will cause the test-case process to invoke exit
  • The return code of exit satisifies predicate
  • regex matches the stderr output resulting from statement

The standard function exit(N) causes the calling program to terminate normally with return code N: hence the documentation:

::testing::ExitedWithCode(exit_code)

This expression is true if the program exited normally with the given exit code.

The author of the answer that you want to make "more straightforward" has sketched a test-case that essentially asserts:-

  • If the test-case process launches a boost::process c and then waits for c to finish, then c will be found to have invoked exit(0).

Which may well be true.

You have written a test case that asserts:-

  • If the test-case process launches a boost::process c and then terminates c, with c.terminate(), then terminating c with c.terminate() will cause the test-case process to invoke exit(0).

Which is certainly false.

Futhermore, c.terminate() does not give c the opportunity to eat a last meal, smoke a last cigarette or terminate normally by calling exit. It just shoots c in the head. So even if your test case did test whether c called exit(0) as a result of c.terminate(), you would find that it doesn't.

Best go with the answer you linked to, as it stands.

Contd. for OP's comments

You're hoping to hear how it is possible to apply googletest death-test macros to death-tests of processes other than the test-case process. That is not possible. The documentation of death-tests is all here. To death-test processes other than the test-case process you'll have to use the general-purpose ASSERT/EXPECT macros, in the way indicated by the answer you linked to.

Going that way, if you wish to test s.status() for any specific terminating signal conditions then you will need to get the relevant information out of s.status() in an OS-specific manner and ASSERT/EXPECT that it what it should be. If your OS is Posix-conforming (e.g. Linux), then see, for example, boost::process::posix_status

If your target program contains functions or classes whose behaviour you would like to subject to death-tests then you always have the option of using googletest to do this in the intended manner, i.e. by factoring those functions or classes into a library that is linked by your target program and then death-testing that library with the death-test macros.

Community
  • 1
  • 1
Mike Kinghan
  • 55,740
  • 12
  • 153
  • 182
  • Well, I was expecting to hear, how it is possible to realize with an **external process**, the suggested approach by the googletest : `TEST(MyDeathTest, NormalExit) { EXPECT_EXIT(NormalExit(), ::testing::ExitedWithCode(0), "Success"); } TEST(MyDeathTest, KillMyself) { EXPECT_EXIT(KillMyself(), ::testing::KilledBySignal(SIGKILL), "Sending myself unblockable signal"); }` verifies that: calling `NormalExit()` causes the process to print "Success" to `stderr` and `exit` with `exit code 0`, and calling `KillMyself()` kills the process with signal `SIGKILL` – HeinrichStack Nov 08 '16 at 08:56