|
| 1 | +// Copyright 2005, Google Inc. |
| 2 | +// All rights reserved. |
| 3 | +// |
| 4 | +// Redistribution and use in source and binary forms, with or without |
| 5 | +// modification, are permitted provided that the following conditions are |
| 6 | +// met: |
| 7 | +// |
| 8 | +// * Redistributions of source code must retain the above copyright |
| 9 | +// notice, this list of conditions and the following disclaimer. |
| 10 | +// * Redistributions in binary form must reproduce the above |
| 11 | +// copyright notice, this list of conditions and the following disclaimer |
| 12 | +// in the documentation and/or other materials provided with the |
| 13 | +// distribution. |
| 14 | +// * Neither the name of Google Inc. nor the names of its |
| 15 | +// contributors may be used to endorse or promote products derived from |
| 16 | +// this software without specific prior written permission. |
| 17 | +// |
| 18 | +// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS |
| 19 | +// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT |
| 20 | +// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR |
| 21 | +// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT |
| 22 | +// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, |
| 23 | +// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT |
| 24 | +// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, |
| 25 | +// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY |
| 26 | +// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT |
| 27 | +// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE |
| 28 | +// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. |
| 29 | +// |
| 30 | +// Author: [email protected] (Zhanyong Wan) |
| 31 | +// |
| 32 | +// The Google C++ Testing Framework (Google Test) |
| 33 | +// |
| 34 | +// This header file defines the public API for death tests. It is |
| 35 | +// #included by gtest.h so a user doesn't need to include this |
| 36 | +// directly. |
| 37 | + |
| 38 | +#ifndef GTEST_INCLUDE_GTEST_GTEST_DEATH_TEST_H_ |
| 39 | +#define GTEST_INCLUDE_GTEST_GTEST_DEATH_TEST_H_ |
| 40 | + |
| 41 | +#include "gtest/internal/gtest-death-test-internal.h" |
| 42 | + |
| 43 | +namespace testing { |
| 44 | + |
| 45 | +// This flag controls the style of death tests. Valid values are "threadsafe", |
| 46 | +// meaning that the death test child process will re-execute the test binary |
| 47 | +// from the start, running only a single death test, or "fast", |
| 48 | +// meaning that the child process will execute the test logic immediately |
| 49 | +// after forking. |
| 50 | +GTEST_DECLARE_string_(death_test_style); |
| 51 | + |
| 52 | +#if GTEST_HAS_DEATH_TEST |
| 53 | + |
| 54 | +namespace internal { |
| 55 | + |
| 56 | +// Returns a Boolean value indicating whether the caller is currently |
| 57 | +// executing in the context of the death test child process. Tools such as |
| 58 | +// Valgrind heap checkers may need this to modify their behavior in death |
| 59 | +// tests. IMPORTANT: This is an internal utility. Using it may break the |
| 60 | +// implementation of death tests. User code MUST NOT use it. |
| 61 | +GTEST_API_ bool InDeathTestChild(); |
| 62 | + |
| 63 | +} // namespace internal |
| 64 | + |
| 65 | +// The following macros are useful for writing death tests. |
| 66 | + |
| 67 | +// Here's what happens when an ASSERT_DEATH* or EXPECT_DEATH* is |
| 68 | +// executed: |
| 69 | +// |
| 70 | +// 1. It generates a warning if there is more than one active |
| 71 | +// thread. This is because it's safe to fork() or clone() only |
| 72 | +// when there is a single thread. |
| 73 | +// |
| 74 | +// 2. The parent process clone()s a sub-process and runs the death |
| 75 | +// test in it; the sub-process exits with code 0 at the end of the |
| 76 | +// death test, if it hasn't exited already. |
| 77 | +// |
| 78 | +// 3. The parent process waits for the sub-process to terminate. |
| 79 | +// |
| 80 | +// 4. The parent process checks the exit code and error message of |
| 81 | +// the sub-process. |
| 82 | +// |
| 83 | +// Examples: |
| 84 | +// |
| 85 | +// ASSERT_DEATH(server.SendMessage(56, "Hello"), "Invalid port number"); |
| 86 | +// for (int i = 0; i < 5; i++) { |
| 87 | +// EXPECT_DEATH(server.ProcessRequest(i), |
| 88 | +// "Invalid request .* in ProcessRequest()") |
| 89 | +// << "Failed to die on request " << i; |
| 90 | +// } |
| 91 | +// |
| 92 | +// ASSERT_EXIT(server.ExitNow(), ::testing::ExitedWithCode(0), "Exiting"); |
| 93 | +// |
| 94 | +// bool KilledBySIGHUP(int exit_code) { |
| 95 | +// return WIFSIGNALED(exit_code) && WTERMSIG(exit_code) == SIGHUP; |
| 96 | +// } |
| 97 | +// |
| 98 | +// ASSERT_EXIT(client.HangUpServer(), KilledBySIGHUP, "Hanging up!"); |
| 99 | +// |
| 100 | +// On the regular expressions used in death tests: |
| 101 | +// |
| 102 | +// On POSIX-compliant systems (*nix), we use the <regex.h> library, |
| 103 | +// which uses the POSIX extended regex syntax. |
| 104 | +// |
| 105 | +// On other platforms (e.g. Windows), we only support a simple regex |
| 106 | +// syntax implemented as part of Google Test. This limited |
| 107 | +// implementation should be enough most of the time when writing |
| 108 | +// death tests; though it lacks many features you can find in PCRE |
| 109 | +// or POSIX extended regex syntax. For example, we don't support |
| 110 | +// union ("x|y"), grouping ("(xy)"), brackets ("[xy]"), and |
| 111 | +// repetition count ("x{5,7}"), among others. |
| 112 | +// |
| 113 | +// Below is the syntax that we do support. We chose it to be a |
| 114 | +// subset of both PCRE and POSIX extended regex, so it's easy to |
| 115 | +// learn wherever you come from. In the following: 'A' denotes a |
| 116 | +// literal character, period (.), or a single \\ escape sequence; |
| 117 | +// 'x' and 'y' denote regular expressions; 'm' and 'n' are for |
| 118 | +// natural numbers. |
| 119 | +// |
| 120 | +// c matches any literal character c |
| 121 | +// \\d matches any decimal digit |
| 122 | +// \\D matches any character that's not a decimal digit |
| 123 | +// \\f matches \f |
| 124 | +// \\n matches \n |
| 125 | +// \\r matches \r |
| 126 | +// \\s matches any ASCII whitespace, including \n |
| 127 | +// \\S matches any character that's not a whitespace |
| 128 | +// \\t matches \t |
| 129 | +// \\v matches \v |
| 130 | +// \\w matches any letter, _, or decimal digit |
| 131 | +// \\W matches any character that \\w doesn't match |
| 132 | +// \\c matches any literal character c, which must be a punctuation |
| 133 | +// . matches any single character except \n |
| 134 | +// A? matches 0 or 1 occurrences of A |
| 135 | +// A* matches 0 or many occurrences of A |
| 136 | +// A+ matches 1 or many occurrences of A |
| 137 | +// ^ matches the beginning of a string (not that of each line) |
| 138 | +// $ matches the end of a string (not that of each line) |
| 139 | +// xy matches x followed by y |
| 140 | +// |
| 141 | +// If you accidentally use PCRE or POSIX extended regex features |
| 142 | +// not implemented by us, you will get a run-time failure. In that |
| 143 | +// case, please try to rewrite your regular expression within the |
| 144 | +// above syntax. |
| 145 | +// |
| 146 | +// This implementation is *not* meant to be as highly tuned or robust |
| 147 | +// as a compiled regex library, but should perform well enough for a |
| 148 | +// death test, which already incurs significant overhead by launching |
| 149 | +// a child process. |
| 150 | +// |
| 151 | +// Known caveats: |
| 152 | +// |
| 153 | +// A "threadsafe" style death test obtains the path to the test |
| 154 | +// program from argv[0] and re-executes it in the sub-process. For |
| 155 | +// simplicity, the current implementation doesn't search the PATH |
| 156 | +// when launching the sub-process. This means that the user must |
| 157 | +// invoke the test program via a path that contains at least one |
| 158 | +// path separator (e.g. path/to/foo_test and |
| 159 | +// /absolute/path/to/bar_test are fine, but foo_test is not). This |
| 160 | +// is rarely a problem as people usually don't put the test binary |
| 161 | +// directory in PATH. |
| 162 | +// |
| 163 | +// TODO([email protected]): make thread-safe death tests search the PATH. |
| 164 | + |
| 165 | +// Asserts that a given statement causes the program to exit, with an |
| 166 | +// integer exit status that satisfies predicate, and emitting error output |
| 167 | +// that matches regex. |
| 168 | +# define ASSERT_EXIT(statement, predicate, regex) \ |
| 169 | + GTEST_DEATH_TEST_(statement, predicate, regex, GTEST_FATAL_FAILURE_) |
| 170 | + |
| 171 | +// Like ASSERT_EXIT, but continues on to successive tests in the |
| 172 | +// test case, if any: |
| 173 | +# define EXPECT_EXIT(statement, predicate, regex) \ |
| 174 | + GTEST_DEATH_TEST_(statement, predicate, regex, GTEST_NONFATAL_FAILURE_) |
| 175 | + |
| 176 | +// Asserts that a given statement causes the program to exit, either by |
| 177 | +// explicitly exiting with a nonzero exit code or being killed by a |
| 178 | +// signal, and emitting error output that matches regex. |
| 179 | +# define ASSERT_DEATH(statement, regex) \ |
| 180 | + ASSERT_EXIT(statement, ::testing::internal::ExitedUnsuccessfully, regex) |
| 181 | + |
| 182 | +// Like ASSERT_DEATH, but continues on to successive tests in the |
| 183 | +// test case, if any: |
| 184 | +# define EXPECT_DEATH(statement, regex) \ |
| 185 | + EXPECT_EXIT(statement, ::testing::internal::ExitedUnsuccessfully, regex) |
| 186 | + |
| 187 | +// Two predicate classes that can be used in {ASSERT,EXPECT}_EXIT*: |
| 188 | + |
| 189 | +// Tests that an exit code describes a normal exit with a given exit code. |
| 190 | +class GTEST_API_ ExitedWithCode { |
| 191 | + public: |
| 192 | + explicit ExitedWithCode(int exit_code); |
| 193 | + bool operator()(int exit_status) const; |
| 194 | + private: |
| 195 | + // No implementation - assignment is unsupported. |
| 196 | + void operator=(const ExitedWithCode& other); |
| 197 | + |
| 198 | + const int exit_code_; |
| 199 | +}; |
| 200 | + |
| 201 | +# if !GTEST_OS_WINDOWS |
| 202 | +// Tests that an exit code describes an exit due to termination by a |
| 203 | +// given signal. |
| 204 | +class GTEST_API_ KilledBySignal { |
| 205 | + public: |
| 206 | + explicit KilledBySignal(int signum); |
| 207 | + bool operator()(int exit_status) const; |
| 208 | + private: |
| 209 | + const int signum_; |
| 210 | +}; |
| 211 | +# endif // !GTEST_OS_WINDOWS |
| 212 | + |
| 213 | +// EXPECT_DEBUG_DEATH asserts that the given statements die in debug mode. |
| 214 | +// The death testing framework causes this to have interesting semantics, |
| 215 | +// since the sideeffects of the call are only visible in opt mode, and not |
| 216 | +// in debug mode. |
| 217 | +// |
| 218 | +// In practice, this can be used to test functions that utilize the |
| 219 | +// LOG(DFATAL) macro using the following style: |
| 220 | +// |
| 221 | +// int DieInDebugOr12(int* sideeffect) { |
| 222 | +// if (sideeffect) { |
| 223 | +// *sideeffect = 12; |
| 224 | +// } |
| 225 | +// LOG(DFATAL) << "death"; |
| 226 | +// return 12; |
| 227 | +// } |
| 228 | +// |
| 229 | +// TEST(TestCase, TestDieOr12WorksInDgbAndOpt) { |
| 230 | +// int sideeffect = 0; |
| 231 | +// // Only asserts in dbg. |
| 232 | +// EXPECT_DEBUG_DEATH(DieInDebugOr12(&sideeffect), "death"); |
| 233 | +// |
| 234 | +// #ifdef NDEBUG |
| 235 | +// // opt-mode has sideeffect visible. |
| 236 | +// EXPECT_EQ(12, sideeffect); |
| 237 | +// #else |
| 238 | +// // dbg-mode no visible sideeffect. |
| 239 | +// EXPECT_EQ(0, sideeffect); |
| 240 | +// #endif |
| 241 | +// } |
| 242 | +// |
| 243 | +// This will assert that DieInDebugReturn12InOpt() crashes in debug |
| 244 | +// mode, usually due to a DCHECK or LOG(DFATAL), but returns the |
| 245 | +// appropriate fallback value (12 in this case) in opt mode. If you |
| 246 | +// need to test that a function has appropriate side-effects in opt |
| 247 | +// mode, include assertions against the side-effects. A general |
| 248 | +// pattern for this is: |
| 249 | +// |
| 250 | +// EXPECT_DEBUG_DEATH({ |
| 251 | +// // Side-effects here will have an effect after this statement in |
| 252 | +// // opt mode, but none in debug mode. |
| 253 | +// EXPECT_EQ(12, DieInDebugOr12(&sideeffect)); |
| 254 | +// }, "death"); |
| 255 | +// |
| 256 | +# ifdef NDEBUG |
| 257 | + |
| 258 | +# define EXPECT_DEBUG_DEATH(statement, regex) \ |
| 259 | + GTEST_EXECUTE_STATEMENT_(statement, regex) |
| 260 | + |
| 261 | +# define ASSERT_DEBUG_DEATH(statement, regex) \ |
| 262 | + GTEST_EXECUTE_STATEMENT_(statement, regex) |
| 263 | + |
| 264 | +# else |
| 265 | + |
| 266 | +# define EXPECT_DEBUG_DEATH(statement, regex) \ |
| 267 | + EXPECT_DEATH(statement, regex) |
| 268 | + |
| 269 | +# define ASSERT_DEBUG_DEATH(statement, regex) \ |
| 270 | + ASSERT_DEATH(statement, regex) |
| 271 | + |
| 272 | +# endif // NDEBUG for EXPECT_DEBUG_DEATH |
| 273 | +#endif // GTEST_HAS_DEATH_TEST |
| 274 | + |
| 275 | +// EXPECT_DEATH_IF_SUPPORTED(statement, regex) and |
| 276 | +// ASSERT_DEATH_IF_SUPPORTED(statement, regex) expand to real death tests if |
| 277 | +// death tests are supported; otherwise they just issue a warning. This is |
| 278 | +// useful when you are combining death test assertions with normal test |
| 279 | +// assertions in one test. |
| 280 | +#if GTEST_HAS_DEATH_TEST |
| 281 | +# define EXPECT_DEATH_IF_SUPPORTED(statement, regex) \ |
| 282 | + EXPECT_DEATH(statement, regex) |
| 283 | +# define ASSERT_DEATH_IF_SUPPORTED(statement, regex) \ |
| 284 | + ASSERT_DEATH(statement, regex) |
| 285 | +#else |
| 286 | +# define EXPECT_DEATH_IF_SUPPORTED(statement, regex) \ |
| 287 | + GTEST_UNSUPPORTED_DEATH_TEST_(statement, regex, ) |
| 288 | +# define ASSERT_DEATH_IF_SUPPORTED(statement, regex) \ |
| 289 | + GTEST_UNSUPPORTED_DEATH_TEST_(statement, regex, return) |
| 290 | +#endif |
| 291 | + |
| 292 | +} // namespace testing |
| 293 | + |
| 294 | +#endif // GTEST_INCLUDE_GTEST_GTEST_DEATH_TEST_H_ |
0 commit comments