Testing SharedReaderKeys requires using withKnownIssue which doesn't feel right

[adamjcampbell]

Currently to test SharedReaderKey failures we are required to use withKnownIssue as Sharing reports these issues internally with no way to control the behaviour.

For example:

swift-sharing/Tests/SharingTests/FileStorageTests.swift

Lines 139 to 147 in 813b8b5

	try withKnownIssue {
	@Shared(.fileStorage(.fileURL)) var users = [User]()
	let loadError = try #require($users.loadError)
	#expect(loadError is DecodingError)
	$users.withLock { $0.append(User(id: 1, name: "Blob")) }
	#expect($users.loadError == nil)
	} matching: {
	$0.error is DecodingError
	}

From the WWDC session Go further with Swift Testing we can gain some insight into the purpose of withKnownIssue

Next, let’s go over how to document known errors in your test using the withKnownIssue function.

Triaging test failures is a time-consuming process. When you cannot immediately fix a failing test, or if it’s failing due to factors outside of your control, the failure can add noise to your test results that obscures real customer-facing problems.

This test is checking that a soft serve ice cream machine can make an ice cream cone, but it looks like the machine is out of service right now and the test is failing as a result.

It may be a while before the mechanic can fix the machine.

While you're waiting for them to arrive, your first intuition may be to use the disabled trait on this test.

However, withKnownIssue is a better option in this case. The test will continue to run and you will be notified of compilation errors.

If the function returns an error, the test’s results will not count towards a test failure, as this failure is expected. Instead, the test will be surfaced as an expected failure in the results. When the issue is fixed and an error is no longer thrown, you'll be notified, and you can go ahead and remove the withKnownIssue call and run the test normally again.

We can see from the presentation here, as well as the behaviour in Xcode (grey diamond instead of green diamond) that this feature is to mark tests as poorly behaving to remediate later.

However we actually want our tests of SharedReaderKey implementations correctly handling errors to go green. So we need some way to control this behaviour.

@lukeredpath has started some work in Issue Reporting to address this here however I wonder if the correct place to fix this isn't in Sharing itself.

As I'm fairly new to the Sharing codebase I'm looking to get some agreement or direction, if others agree I'm happy to work on an implementation to implement the suggestion.

[lukeredpath]

FWIW my use case for this fix had nothing to do with Sharing so I’m not sure this library is the right place to fix this.

[adamjcampbell]

Ah I think there's perhaps two separate issues then:
This one is: For issues not to be reported in an uncontrollable manner in Shared
The other is to be able to test that issues are successfully reported

[stephencelis]

We agree. We're thinking on various changes at the Issue Reporting level, but also don't think Sharing should report these issues outside of debug builds, and certainly not during tests. When this PR lands the next release should fix things: #144

[adamjcampbell]

It is released as far as I can see and I have tested it in my own project. Thanks for your work 😄