3 ms·
Even with multiple assertions the test failure reason should be quite clear as most testing frameworks allow to specify a message which is then output in the te
by _lambdalambda 4y ago
Even with multiple assertions the test failure reason should be quite clear as most testing frameworks allow to specify a message which is then output in the testing summary.
E.g. `assertEqual(actual_return_code, 200, "bad status code")` should lead to output like `FAILED: test_when_delete_user_then_ok (bad status code, expected 200 got 404)`
- TeMPOraL 4y agoEven if you don't specify the message, at the very minimum, the output should look like: FAILED: test_when_delete_user_then_ok Assertion failed: `actual_return_code' expected `200', got `400'. Note it mentions the actual expression put in the assert. Which makes it almost always uniquely identifiable within the test. That's the bare minimum I'd expect of a testing framework - if it can't do that, then what's the point of having it? It's probably better to just write your own executable and throw exceptions in conditionals. What I expect from a testing framework is at least this: FAILED: test_when_delete_user_then_ok Assertion failed: `actual_return_code' expected `200', got `400'. In file: '/src/blah/bleh/blop/RestApiTests.cs:212'. I.e. to also identify the file and the line containing the failing assertion. If your testing framework doesn't do that, then again, what's even the point of using it? Throwing an exception or calling language's built-in assert() on a conditional will likely provide at least the file+line.