Skip to content
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

Open
lukeredpath opened this issue Feb 6, 2025 · 1 comment · May be fixed by #146
Open

Cannot disable test failure behaviour #145

lukeredpath opened this issue Feb 6, 2025 · 1 comment · May be fixed by #146

Comments

@lukeredpath
Copy link

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 use withExpectedIssue because the async version does not support XCTest - I cannot change over to Swift testing just to work around this issue. I can use XCTExpectFailure() 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.

@lukeredpath
Copy link
Author

lukeredpath commented Feb 6, 2025

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 client dependency to throw an error to test that the error is caught and I receive the .somethingFailed action. I don't particularly care in my test that the error was reported.

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 reportIssue call. This example is a heavily simplified version of an actual test.

  1. I don't want to use XCTExpectFailure here because I don't actually think the test is failing and this might mask a real failure.
  2. I can't wrap this code with withExpectedIssue because the async version of this only works with Swift Testing.

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:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant