[SERVER-29041] failing unit tests or dbtests should print backtrace Created: 02/May/17 Updated: 07/Mar/18 Resolved: 07/Mar/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Charlie Swanson | Assignee: | DO NOT USE - Backlog - Test Infrastructure Group (TIG) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | tig-unittests | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Description |
|
Ideally our unit tests are simple enough that it's obvious which line failed and for what reason, but this isn't always the case. For example, some of the old DocumentSourceGroup tests give you almost no indication of what went wrong if the test fails. In this case, you need to resort to print statements or gdb to figure out what was going on. |
| Comments |
| Comment by Max Hirschhorn [ 07/Mar/18 ] |
|
Closing as a duplicate of |
| Comment by Andy Schwerin [ 03/May/17 ] |
|
Hmmm. I don't want print-on-throw behavior, because swallowed errors shouldn't produce misleading stack traces. We could collect the trace and attach it to the failure, though, for later printing. |
| Comment by Charlie Swanson [ 02/May/17 ] |
|
One of these tests failed while working with Ryan on Pull Request 1143, and it was pretty hard to debug, especially for someone unfamiliar with the codebase or gdb. |