[SERVER-28567] assert.throws should validate that the correct exception was thrown Created: 31/Mar/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kevin Pulo | Assignee: | Backlog - Server Tooling and Methods (STM) (Inactive) |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | stm | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Server Tooling & Methods
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
assert.throws() makes no effort to ensure that the exception that was thrown is the one that should have been thrown. There are lots of problems which can cause exceptions to be thrown, many of which are completely unrelated to what is being tested. If one of these problems is inadvertently introduced, assert.throws() will continue to succeed when it really ought to fail. Examples of this include It would be better if users of assert.throws() were forced to (somehow) declare the exception that is expected to occur (eg. via substring matching?). |
| Comments |
| Comment by Steven Vannelli [ 10/May/22 ] |
|
Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions. |
| Comment by Max Hirschhorn [ 04/Apr/17 ] |
|
Based on discussion during TIG team triage, we think it's worth running a patch build to see whether any usages of assert.throws() are specifically designed to catch ReferenceError or TypeError by having assert.throws() propagate the exception if they are of that type. |