[FR]: Allow EXPECT_NONFATAL_FAILURE and EXPECT_FATAL_FAILURE to expect more than one failure

[daantimmer]

Does the feature exist in the most recent commit?

No

Why do we need this feature?

GoogleTest and GoogleMock allow multiple failures to be thrown. By using, for example, EXPECT_THAT....

GoogleTest also allows it to be used as an foundation/framework for other test frameworks. I so happen to be doing exactly that. And I have multiple tests that would have multiple EXPECT calls to fail in one test.

However, EXPECT_NONFATAL_FAILURE and EXPECT_FATAL_FAILURE only allow for one error to be thrown.

Describe the proposal.

Either extend/augment the function-like-macro for EXPECT_NONFATAL_FAILURE and EXPECT_FATAL_FAILURE to accept an integer for the amount of failures or allow the substr to be of a list/initializerlist/vector type to expect multiple (different?) substrings.

or

Add a second pair of EXPECT_NONFATAL_FAILURE and EXPECT_FATAL_FAILURE, for example, EXPECT_MULTIPLE_NONFATAL_FAILURE and its brother EXPECT_MULTIPLE_FATAL_FAILURE taking a list of substr to match against.

Is the feature specific to an operating system, compiler, or build system version?

No

[daantimmer]

A solution that I currently used to work around the issue is create my own TestPartResultReporterInterface by inheriting from ScopedFakeTestPartResultReporter. The reason for inheriting from ScopedFakeTestPartResultReporter is because I else would have had to use the 'testing::internal::UnitTestImplclass which is considered to be private. I've overriden theReportTestPartResult` and thats it. Problem solved.

But it feels very dirty.

[dexoryn]

You’re absolutely right that while GoogleTest/GoogleMock support multiple EXPECT_* failures within a single test, the helper macros EXPECT_NONFATAL_FAILURE and EXPECT_FATAL_FAILURE are currently limited to asserting only a single failure. This makes them awkward to use when:

A test is expected to intentionally trigger multiple independent failures, or

GoogleTest is used as a foundation for higher-level test frameworks that aggregate expectations.

The proposed extensions make sense from an API ergonomics standpoint. In particular:

Allowing an expected failure count would align well with how users reason about grouped expectations.

Supporting a list / initializer_list of substrings would enable more precise validation without forcing fragile test structure.

Introducing explicit macros like EXPECT_MULTIPLE_NONFATAL_FAILURE(S) could preserve backward compatibility while making intent clearer.

One thing worth considering is how failure ordering should be handled (strict vs unordered matching), as well as how this interacts with existing internal failure reporters.

Overall, this feels like a reasonable enhancement that would improve GoogleTest’s usefulness for advanced and compositional testing scenarios. Happy to help review or prototype an approach if there’s interest.

[SuperAdam47]

That's make sense.
But I think we can find other solutions to handle the failure

[Mahmoud-Eltohamy]

hello all
i would like to work on this issue, is it still available?