-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot disable test failure behaviour #145
Comments
Expanded example of why this isn't always helpful: We have an effect that performs some work and if an error is thrown, we catch it and send a different action back to the store. However it is still useful for reporting purposes to report this issue. A simplified example of what this might look like: return .run { send in
do {
try await client.somethingImporant()
await send(.somethingWorked)
} catch {
reportIssue(error)
await send(.somethingFailed)
}
} If I'm testing the failure flow, I might override the let store = TestStore(...)
store.dependencies.client.somethingImportant = { throw SomeError() }
// this action returns the effect above
await store.send(.task)
await store.receive(.somethingFailed) The above test fails due to the unhandled
I just want to disable the exhaustive asserting against reported issues, its just not important to this test. Edit to say: on Stephen's suggestion I tried using the issue matcher for XCTExpectFailure {
$0.compactDescription.hasPrefix("failed - Caught error:")
} This sort of works around the issue, but I don't like that I lose my green "test passed" tick and have to settle for lots of grey X status indicators across my test suite for tests that I consider to be a pass. |
The library automatically causes tests to fail when
reportIssue
is called, which is not always desirable behaviour and there is no easy way to stop this from happening.I'm in the process of migrating our custom error handling code over to using swift-issue-reporting. Our app uses TCA. I already have a number of tests where I'm explicitly configuring a dependency to throw an error to test the error handling path - even if we have explicit error handling logic we might still use
reportIssue
to log that issue (to Sentry, using a custom reporter). There is no need for this to trigger a test failure.I expected that this behaviour was just a custom "test" reporter but it isn't, it is hardcoded into
reportIssue
. I cannot usewithExpectedIssue
because the async version does not support XCTest - I cannot change over to Swift testing just to work around this issue. I can useXCTExpectFailure()
directly but this is a very broad solution that could hide genuine test failures.I think this behaviour should be configurable, or refactored into a default issue reporter that can be overridden using the existing API for configuring reporters.
The text was updated successfully, but these errors were encountered: