[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 ] | |||
| 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
(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. |