Add public init to client call unary stubs.

[mpetrov]

Currently initializing test stubs from a different module fails.

[rebello95]

If this is intended for testing purposes, what are your thoughts on using @testable import instead?

[MrMage]

Agree with @rebello95, IIRC we kept these internal to avoid cluttering the interface while keeping them available through @testable. Thinking about this more, should we revert the recent similar PR that made a different initializer public for testing purposes?

[mpetrov]

I'm generally not a huge fan of @testable importing test utilities personally. I would expect @testable import SwiftGRPC to be needed when unit-testing SwiftGRPC itself, but not by other projects. e.g. I import XCTest, I should not need to @testable import XCTest.
There's no way to know if something in SwiftGRPC is internal because it's internal to the library, or internal because it's meant for testing.

Do y'all have thoughts on just splitting out stub & testing code from the production sources?

[MrMage]

I'm generally not a huge fan of @testable importing test utilities personally. I would expect @testable import SwiftGRPC to be needed when unit-testing SwiftGRPC itself, but not by other projects. e.g. I import XCTest, I should not need to @testable import XCTest.

Are there any statements on this from other sources, or examples we could follow?

There's no way to know if something in SwiftGRPC is internal because it's internal to the library, or internal because it's meant for testing.

This should be solvable with headerdocs.

Do y'all have thoughts on just splitting out stub & testing code from the production sources?

Is this what your other PR is about?

[MrMage]

Sorry, I have only now looked at the context of this particular change. I agree that this initializer should be public, which would also be consistent with our other TestStub implementations. If @rebello95 is okay with this, I'd propose merging this PR while continuing the related discussions on best practices for testing.

[mpetrov]

To be honest, I'm struggling to find any sources from Apple that either support or disprove my statement. It seems there is very little official guidance.
There are some discussions about @testable on Swift forums, but it's hard to make anything conclusive out of it: https://forums.swift.org/t/the-future-of-testable/9655

PR #402 is about splitting up the generated code, but I would like to apply the same principle to the runtime as well. I don't think the dead code eliminator is powerful enough to drop public and open members right now, so stubs would end up released binaries. If the stubs are split out from the runtime, then presumably there's no need to restrict the visibility as strictly.

[rebello95]

If @rebello95 is okay with this, I'd propose merging this PR while continuing the related discussions on best practices for testing.

This is fine with me

[MrMage]

PR #402 is about splitting up the generated code, but I would like to apply the same principle to the runtime as well. I don't think the dead code eliminator is powerful enough to drop public and open members right now, so stubs would end up released binaries. If the stubs are split out from the runtime, then presumably there's no need to restrict the visibility as strictly.

Sounds good to me, provided it doesn't make SwiftGRPC harder to use and test from a library user perspective.