> If you know the file and line of the assertion, plus the values that are being checked, there's not as much need for a stringified version of the expression.
It does save time. With the actual condition reproduced, half the time I don't even need to check the source of the failed test to know what went bad and where to fix it. Consider the difference between:
FAILED: Expected 1, got 4
In /src/foo/ApiTest.cpp:123
vs.
FAILED: response.status evaluated to 4
expected: 1
In /src/foo/ApiTest.cpp:123
vs.
FAILED: response.status evaluated to Response::invalidArg (4)
expected: Response::noData (1)
In /src/foo/ApiTest.cpp:123
This is also why I insist on adding custom matchers and printers in Google Test for C++. Without it, 90% of the time a failed assertion/expectation just prints "binary objects differ" and spews a couple lines of hexadecimal digits. Adding a custom printer or matcher takes little work, but makes all such failures print meaningful information instead, allowing one to just eyeball the problem from test output (useful particularly with CI logs).
It does save time. With the actual condition reproduced, half the time I don't even need to check the source of the failed test to know what went bad and where to fix it. Consider the difference between:
vs. vs. This is also why I insist on adding custom matchers and printers in Google Test for C++. Without it, 90% of the time a failed assertion/expectation just prints "binary objects differ" and spews a couple lines of hexadecimal digits. Adding a custom printer or matcher takes little work, but makes all such failures print meaningful information instead, allowing one to just eyeball the problem from test output (useful particularly with CI logs).