[CXX-1110] Add REQUIRE_THROWS_AS_WITH_CODE test macro Created: 01/Nov/16 Updated: 30/Jun/23 |
|
| Status: | Backlog |
| Project: | C++ Driver |
| Component/s: | Testing |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | error-handling | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Epic Link: | C++ Error Improvements | ||||||||
| Description |
|
The REQUIRE_THROWS_AS macro from the Catch testing framework allows tests to declare the type of the exception expected to be thrown in an expression. However, no mechanism exists for introspecting the error code associated with the exception thrown. Adding a macro such as REQUIRE_THROWS_AS_WITH_CODE would allow for easy creation of tests that fully verify the correctness of the exception thrown. |
| Comments |
| Comment by J Rassi [ 22/Feb/17 ] |
|
Fair point. Added CXX-834 as a dependency, kicked out to "Future API change release". |
| Comment by David Golden [ 22/Feb/17 ] |
|
I agree with the proposal to kick it out. Side note regarding #1: I'm OK leaving the public API unspecified, even if our tests have server-version-specific expectations. I think the benefit of falsifiable tests outweighs the cost of increased fragility. |
| Comment by J Rassi [ 15/Feb/17 ] |
|
I originally filed this ticket after discussion with david.golden regarding a mongocxx::uri test which verified the correctness of the code associated with the error thrown. The test in question is here: https://github.com/mongodb/mongo-cxx-driver/blob/r3.1.1/src/mongocxx/test/uri.cpp#L37-L42. Originally I was thinking that, as part of the work for this ticket, we would go ahead and replace all existing uses of REQUIRE_THROWS_AS() with REQUIRE_THROWS_AS_WITH_CODE(), passing in whatever code the API method in question happens to throw today. However, I'm now less confident that the approach above is the best approach. In particular, here are some open questions:
I'm tempted to make this depend on CXX-834, kick it out to "Future API change release", and refrain from checking error codes in tests. david.golden, what do you think? cc sam.rossi. |