[SERVER-50649] Execute fixture teardown as part of Test::run Created: 31/Aug/20  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: servicearch-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Service Arch
Operating System: ALL
Participants:

 Description   

Test fixtures' teardown methods are currently executed as part the UnitTestEnvironment destructor, potentially resulting in a loss of exception infos: when an exception is thrown during teardown, the stack is unwinded before throwing. However, in case of additional exception being thrown by an unwind destructor, the program is terminated right away with the current backtrace.

As a result, the original teardown exception is going to be hidden, making debug extremely difficult.

Following the pattern implemented by googletest::UnitTest, the teardown should be executed as part of Test::run .

 



 Comments   
Comment by Lauren Lewis (Inactive) [ 21/Dec/21 ]

We haven’t heard back from you in at least 1 year, so I'm going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Comment by Billy Donahue [ 17/Nov/20 ]

https://github.com/google/googletest/blob/master/googletest/docs/faq.md#should-i-use-the-constructordestructor-of-the-test-fixture-or-setupteardown-ctorvssetup

Comment by Billy Donahue [ 31/Aug/20 ]

(I'll add my follow-up comment from that thread though)

I misunderstood the difference between UnitTest and the tiny RAII class UnitTestEnvironment. We actually do test->setUp and test->tearDown inside test->run, so that's good. The only problem is that we use this UnitTestEnvironment RAII object to implement the tearDown call inevitably, and we don't have a path to handle the dtor-during-unwind case.

It's unclear that tearDown should run at all if the test throws. Googletest just runs a straightforward sequence that can be simplified as

setUp();
doTest();
tearDown();

(code). They check as they go, to see if the test has marked itself as failed, but there's no exception catching here. If a C++ exception escapes any of those three stages, the sequence doesn't continue to make progress or force tearDown() to happen during an unwind. Our framework does.

Generated at Thu Feb 08 05:23:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.