eson/googletest
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Document ScopedTrace utility

Browse Source
This commit is contained in:
Fedor Trushkin 2018-01-18 10:34:05 +01:00
parent 9c82e7745c
commit 354fc8d8b1
1 changed files with 9 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
googletest/docs/AdvancedGuide.md
View File

@ -787,15 +787,17 @@ If a test sub-routine is called from several places, when an assertion
inside it fails, it can be hard to tell which invocation of the inside it fails, it can be hard to tell which invocation of the
sub-routine the failure is from. You can alleviate this problem using sub-routine the failure is from. You can alleviate this problem using
extra logging or custom failure messages, but that usually clutters up extra logging or custom failure messages, but that usually clutters up
your tests. A better solution is to use the `SCOPED_TRACE` macro: your tests. A better solution is to use the `SCOPED_TRACE` macro or
the `ScopedTrace` utility:
| `SCOPED_TRACE(`_message_`);` | | `SCOPED_TRACE(`_message_`);` | `ScopedTrace trace(`_"file\_path"_`, `_line\_number_`, `_message_`);` |
|:-----------------------------| |:-----------------------------|:----------------------------------------------------------------------|
where _message_ can be anything streamable to `std::ostream`. This where `message` can be anything streamable to `std::ostream`. `SCOPED_TRACE`
macro will cause the current file name, line number, and the given macro will cause the current file name, line number, and the given message to be
message to be added in every failure message. The effect will be added in every failure message. `ScopedTrace` accepts explicit file name and
undone when the control leaves the current lexical scope. line number in arguments, which is useful for writing test helpers. The effect
will be undone when the control leaves the current lexical scope.
For example, For example,